Twee automerken liepen in 2026 tegen een opvallend type probleem aan: geen nieuwe, verborgen softwarefout, maar een bekende configuratie die nog steeds met een standaardwachtwoord draaide. Daardoor konden onderzoekers een inlogomgeving volledig omzeilen, klantaccounts aanpassen en vervolgens via de bijbehorende voertuigcommando’s deuren ontgrendelen en de motor starten.
De casus zegt veel over dreiging en patchvertraging in 2026. Zelfs als kwetsbaarheden al jaren gedocumenteerd zijn, kan één gemiste stap in de uitrol genoeg zijn om een keten van toegang tot accountgegevens én voertuigfuncties te activeren.
Wat ging er mis bij de automerken?
De mobiele apps van beide merken vertrouwden op dezelfde identiteitslaag. Klanten meldden zich aan via een platform dat ForgeRock-servers gebruikte: één onderdeel voor authenticatie en een beheerlaag waarin klantgegevens werden opgeslagen via een component die OpenIDM heet.
Op die servers vonden de onderzoekers een administratorconsole die standaard in de omgeving aanwezig hoort te zijn, maar die volgens de leverancier en de hardeningrichtlijnen vóór productie verwijderd of afgeschermd moet worden. Cruciaal detail: de console gebruikte nog een default gebruikersnaam en wachtwoord. In dit geval was dat admin:admin.
Waarom een edge/WAF-regel niet genoeg was
De administratorconsole was weliswaar geblokkeerd tegen toegang vanaf het open internet. Maar de beveiligingslaag (de “edge” die het verkeer voor de site verwerkt) en de server zelf keken niet altijd op dezelfde manier naar het aangevraagde pad.
De onderzoekers maakten gebruik van een techniek waarbij de URL zodanig werd aangepast (met extra tekens en encoded slashes) dat de edge de request behandelde als een onschuldig statisch bestand. De server interpreteerde dezelfde request echter als een pad naar de console. Met de juiste aanroep en het standaardwachtwoord was toegang tot de beheeromgeving vervolgens mogelijk.
Van adminconsole naar commandoprompt
Eenmaal binnen konden de onderzoekers gebruikmaken van een ingebouwde scheduler in de console. Die scheduler kon kleine scripts uitvoeren op de identiteitserver. Daardoor verkregen ze in feite een command prompt op het systeem dat de klantgegevens van beide automerken bevatte.
De records voor de doelaccounts zaten achter dezelfde logische afscherming als de console. Toch konden de onderzoekers vanuit “binnen” de server wel bij die gegevens. Ze konden dus niet alleen inloggen, maar ook wijzigingen aanbrengen in accountgegevens.
Account overnemen en toegangstokens misbruiken
De aanval draaide vervolgens om het veranderen van een doelaccount (zoals e-mailadres en wachtwoord) en daarna inloggen via de normale app. Zodra zij als die klant waren ingelogd, kregen ze dezelfde toegangstokens als de echte applicatie gebruikt.
Dat is een belangrijke stap: tokens zijn de “sleutels” waarmee de app met de backend communiceert. Met die tokens konden de onderzoekers voertuigcommando’s sturen alsof ze de rechtmatige accountgebruiker waren.
Wat konden ze met de auto’s?
Met de eigen accountcontext en de bijbehorende voertuigcommando’s konden de onderzoekers bij testauto’s de deuren ontgrendelen en de motor starten. Ze gaven aan dat ze daarbij zorgvuldig te werk gingen: de volledige keten testten ze alleen op auto’s van henzelf of van eigenaren die toestemming gaven.
In hun demonstraties ontgrendelden en startten ze een testvoertuig met de eigenaar vlakbij. Daarna stopten en vergrendelden ze de auto weer. Voor de buitenwereld was het effect volgens de onderzoekers relatief lastig te zien.
Waarom het voor bestuurders nauwelijks zichtbaar was
Een opvallend detail is dat het aanpassen van e-mail en wachtwoord er niet automatisch voor zorgde dat de eigenaar direct werd uitgelogd. Bovendien konden de onderzoekers meldingen/alerts richten op hun eigen telefoon, zodat het slachtoffer geen signalen zag op het toestel van de eigenaar.
Dat verkleint de kans dat een gebruiker snel ingrijpt, en vergroot de impact van een aanval die via een identiteitsfout werkt.
Verschillen tussen landen: VS/Canada versus Australië
De onderzoekers beschrijven dat er in de VS dezelfde loginketen zat via de identity-laag die ForgeRock/derivaten gebruikte. Beide systemen werden ongeveer twee uur nadat het probleem werd gerapporteerd opgelost.
Voor Australië lag de ingang anders. Daar bleek dat admin-credentials in de app-code waren achtergelaten, bedoeld voor een testopstelling. De onderzoekers zetten die keten vervolgens apart uiteen, maar gaven niet dezelfde update-tijdlijn als bij de VS.
Geen CVE, wél directe actie nodig
Omdat dit geen nieuwe softwarebug in het product zelf was, kwam er geen CVE en dus ook geen “klassieke” vendor-advisory die je kunt afvinken. De console en het defaultwachtwoord waren volgens de beschrijving al jaren gedocumenteerd, en de hardeninggids zegt operators al om de console te verwijderen of te beveiligen voordat de systemen live gaan.
Dat maakt de les extra relevant voor dreiging en patchvertraging in 2026: als teams geen proces hebben om hardening-richtlijnen strikt te volgen (en periodiek te hercontroleren), kan een bekende configuratie toch leiden tot volledige ketencompromittering.
Wat identity-teams nu moeten controleren
De onderzoekers noemen twee checks die teams moeten uitvoeren wanneer ze dezelfde identity-software (nu onderdeel van PingIDM in de context van de casus) gebruiken:
- Controleer de Apache Felix console op het pad /system/console. Verwijder de console of wijzig het standaardwachtwoord voordat je in productie gaat.
- Ga niet uitsluitend uit van edge/WAF path-regels. Als edge en server hetzelfde verzoekpad niet identiek interpreteren, kan een pad “weggespoeld” worden door de regels terwijl de server toch bij de admininterface uitkomt.
Met andere woorden: je moet de aanvalsvector uitsluiten (console verwijderen/beveiligen), en niet alleen vertrouwen op “onzichtbaarheid” via detectie of filtering.
Gerelateerde risico’s: ook bij andere connected-ecosystemen
Deze casus past in een breder beeld waarin onderzoekers vaak niet de auto zelf aanvallen, maar de websystemen en authenticatielaag achter de apps. In het verleden lieten ze bijvoorbeeld zien dat kwetsbaarheden in connected-car services of webexposures zowel accounttoegang als voertuigfuncties kunnen raken.
Als je dit onderwerp verder wilt verdiepen, lees ook:
- wat een datalek betekent voor slachtoffers en organisaties
- hoe aanvallen op servers kunnen escaleren en impact krijgen
- hoe misbruik van gegevensstromen via moderne systemen kan ontstaan
Conclusie: voorkom dat “known issues” toch toeslaan
Het incident rond default admin:admin laat zien hoe snel een identiteitsomgeving kan worden omgezet in een brug naar accountovernames en voertuigcommando’s. De onderzoekers konden de volledige keten demonstreren, maar de kern ligt bij iets dat teams vaak kunnen voorkomen: standaardinstellingen en onvoldoende hardening.
Voor organisaties die identiteitssoftware gebruiken, is de boodschap helder. Werk hardening af vóór livegang, verwijder of bescherm adminconsoles, en vertrouw niet alleen op edge/WAF-regels. Zo beperk je de kans dat dreiging en patchvertraging in 2026 niet alleen een nieuwslabel is, maar een echte incidenttrigger.
Bron: https://thehackernews.com/2026/11/default-adminadmin-server-password.html
