Default admin:admin Password Let Researchers Start Cars

Two researchers walked through the front door of two carmakers' login systems and drove away — digitally speaking — with the ability to unlock doors, flash headlights, sound horns and start engines on connected cars in Australia and the United States. The master key wasn't a zero-day. According to The Hacker News, it was an administrator console on the ForgeRock identity platform that still answered to the factory password: admin:admin.

Shubham Shah, co-founder at Assetnote, and researcher Sam Curry published the work late last week, as The Register reported. Both automakers — who asked to stay anonymous and got their wish — built their mobile-app logins on ForgeRock, an identity platform now owned by Ping Identity. The pair reported the flaws in early 2026 and, per Curry's disclosure timeline, the holes were patched within about two hours of the report landing. Two hours. Hold that number; it's the whole story.

Two kill chains, one moral

Start with the American attack, because it's the embarrassing one. Both brands signed customers in through ForgeRock, which runs in two parts: a login front end and OpenIDM, the component that stores customer records. OpenIDM ships with a built-in administrator console powered by Apache Felix, and ForgeRock's own hardening guide tells operators — has told them for years — to remove that console or change its password before going live, because it keeps its credentials separately from the rest of the system. On these production servers it was still installed, still reachable, and still using the documented default, the word admin for both username and password.

The console wasn't exposed to the open internet; a web application firewall stood in front of it. That turned out to be a speed bump, not a wall. The edge and the Java software behind it parsed the same URL differently, so by adding encoded slashes and extra characters the researchers made the edge read the request as a harmless static file while the origin server read it as the path to the console. Classic path confusion. Once inside, they used the Felix configuration manager's built-in scheduler to run an inline Groovy script — which is a polite way of saying they got a shell on the identity servers holding both brands' customer records. Shah said the US attack "required a lot more work" because that automaker "spent much more time securing the US, Canadian, and European OpenIDM environments." Draw your own conclusions about what that implies for everywhere else.

From a shell on the identity server, the rest was bookkeeping. The researchers queried local admin API endpoints, changed a target account's email address and password, signed in through the ordinary mobile app, and received the same access tokens the real app gets. Those tokens unlock doors and start engines. They demonstrated exactly that on a test car with the consenting owner standing next to it, then stopped the engine and locked it again.

The Australian chain, detailed in Shah's separate write-up, was different in the front end and identical in spirit. The researchers pulled a vehicle identification number from public licence-plate checkers, fed it to internal APIs, and got back personal information and owner email addresses. Then they found OpenIDM admin credentials hardcoded in the app's code — credentials meant for a staging environment that also worked in production. After bypassing what The Register described as heavy WAF filtering via path traversal flaws, they invoked the internal admin APIs, took over accounts with nothing more than an email address, and minted authentication tokens to send arbitrary commands through the app.

The truly chilling part is how quiet the takeover was. Changing the account's email and password didn't log the owner out of their own app, and the researchers could point the account's alerts at their own phone, keeping the victim's phone silent. They restored the real email after the test. If you were running this maliciously, the owner's first clue would be an empty parking spot.

Confirmed, claimed, and still unknown

Now the discipline. There's a lot of sizzle in this story, and as someone who's sat through a hundred breach post-mortems, I'd rather you know exactly which parts are proven.

• Confirmed by demonstration: the full chain — account takeover through to unlock and engine start — works. The researchers ran it in February 2026 on cars they owned or had permission to use, with an owner physically present.
• Claimed by the researchers: they could have opened a session on any customer account on the affected servers, and the two chains together covered cars in Australia, the US and Canada. They were explicit that they "tested the complete chain only with US accounts and vehicles."
• Confirmed by the vendor's own documentation: the Felix console and its default password have been documented for years, and ForgeRock's production hardening guide already says to remove it or secure it.
• Unknown: whether anyone malicious found this path before it closed. Neither write-up says. Also unknown: when the Australian systems were fixed — Shah's post gives no date, and the two-hour remediation figure comes from the US disclosure timeline.
• Unverified speculation: the automakers' identities. Petrolheads studying Shah's partially blurred demo video decided the wing mirror and unlock chime screamed Toyota, with Lexus as the second brand. Asked whether that was accurate, a Toyota Motor Corporation spokesperson neither confirmed nor denied, per The Register. That's a non-denial, not a name. Treat it accordingly.

Why does the distinction matter? Because there's no CVE here and no vendor advisory to follow. This was a configuration failure, not a product bug — which means there is no patch to scan for, no version number to check against, no neat line item your vulnerability scanner can close. Your exposure depends entirely on how your team deployed the software, and the only way to know is to go look. That's less comforting than a CVE, and it's why this story deserves more of your attention than the average critical-severity advisory that patches itself into a ticket queue.

"Obviously, they have asked not to be named, and while normally we would fight to actually include the company names, it's a busy time in the security world and I don't like the idea of them diverting resources because they are worried about something with this disclosure," Curry said, explaining the unusual decision to grant the carmakers anonymity.

Follow the money: the two-hour fix

Here's the arithmetic that should make a CFO wince. The remediation — remove a console, change a password, clean credentials out of a build, tighten a path rule — took roughly two hours once the report arrived. Call it a few hundred dollars of engineering time, generously. The control that would have prevented the whole thing was reading a hardening guide the vendor had already written, at a cost of approximately one engineer-afternoon during deployment. Against that, weigh what was actually at stake: remote physical access to customers' vehicles on three continents, silent account takeover with the alerts redirected, and the personal data sitting behind those internal APIs. If a criminal crew had found this first — and nothing in either account establishes that they didn't — we'd be discussing thefts, liability, and a recall-grade crisis instead of a researcher demo.

I've made this point before about credential hygiene — the ConnectWise credential breach rhymes with it — and I'll keep making it until it stops being true: the cheapest control in security is the one applied at deployment, and the most expensive is the one applied after publication. These carmakers spent real money securing their identity stack; Shah acknowledged the US environment was noticeably harder to crack. They bought the WAF, they ran the platform, they clearly paid someone to think about it. And the whole edifice rested on a console password that ships in the documentation. This is the identity-management version of buying a vault and leaving the spare key under the mat — the mat being a URL the edge and the server disagreed about.

A word on the WAF, because some vendor will use this story to sell you one. Don't take the bait. Both chains went through the WAF, not around it — twice, in two different environments, using the same class of trick: the edge and the origin parsing a path differently. A WAF rule that hides an admin page is a comfort blanket. If the page exists and answers to admin:admin, the only honest control is to delete the page or change the password. Path confusion is a known, boring, well-trodden technique, and it beat two separate enterprise deployments here.

What your board should ask on Monday

Shah and Curry have been here before — they've demonstrated remote access to vehicles from Honda, Kia, Subaru and others by breaking the web systems behind the apps rather than the cars themselves. That's the pattern boards need to internalize: the car is only as secure as the identity provider in front of it, and the identity provider is only as secure as whoever configured it. If you're a CISO fielding questions this week, skip the slide about nation-state actors. Nobody did anything exotic here. Ask the dull questions instead, because dull is where the bodies are buried:

• When did we last audit our identity stack against the vendor's own production hardening guide — not a framework, the vendor's guide?
• Are there staging credentials, consoles, or service accounts anywhere in our production estate, and who verified that by looking rather than by trusting a spreadsheet?
• If an attacker got a shell on our identity servers, what stops them from rewriting customer account recovery data — and would we even see it?
• Do our account-security alerts route in a way a hijacker can silently redirect?
• When a third party runs identity for us, what does our contract actually entitle us to audit?

That last one deserves emphasis. ForgeRock is enterprise plumbing at countless companies, now sold as PingIDM, and the researchers' advice for teams running it is blunt: look for the Apache Felix console at /system/console, remove it or change its default password, and stop counting on edge path rules to hide admin surfaces. If your identity layer is outsourced or managed, this is the week to exercise whatever audit rights you have and ask for evidence — not attestations — that admin consoles are gone or hardened.

My call: if you run ForgeRock or PingIDM, treat this as act-now, because the check takes minutes and the failure mode is total account takeover with physical consequences attached. Everyone else should treat it as a free lesson in opportunity cost. Two hours to fix. Years of documented warnings. One password the vendor practically begged people to change. The gap between those numbers is where breaches live, and closing it doesn't require a budget line — it requires someone to actually read the manual.