Researchers Took Over Two Automakers' Login Servers Through a Default admin:admin Console and Started a Car. Both Fixed It in Two Hours. Check Your Own Identity Servers for the Same Door

If you run ForgeRock or Ping Identity's OpenIDM, check today whether its Apache Felix web console, at the path /system/console, can be reached from the internet and whether it still accepts the default login of admin and admin. Security researchers Sam Curry and Shubham Shah published a write-up on November 7, 2026 that did exactly this against the identity servers behind two automakers' mobile apps. They went from that console to code execution on the server, changed a customer's email and password, signed in through the normal app, and unlocked and started a test car. Both companies fixed it about two hours after being told. The researchers do not name the automakers, and the write-up reports no one else using the path.

What has been reported

The primary source is Sam Curry's write-up, with a separate piece by Shubham Shah on the Australian systems. The Hacker News summarized it on November 10 and adds nothing we could separate from the write-up, so treat them as one source. The automakers appear only as "Automaker #1" and "Automaker #2." The Hacker News describes it as a deployment mistake, not a product bug, and reports no CVE and no vendor advisory.

The chain, at the level a defender needs:

1. An Apache Felix console, part of the OpenIDM deployment, was reachable from the internet and still accepted its documented default credentials.
2. The public web application firewall blocked sensitive admin paths, but let requests under a static-asset prefix through. The firewall matched patterns on the raw request, while the Java web server decoded encoded slashes, stripped semicolon path parameters and resolved dot segments before choosing a handler. A request the firewall judged harmless reached the console.
3. The console could create an OpenIDM schedule that ran inline script code, which let the researchers run commands on the identity server.
4. From the server they reached OpenIDM's administrative API over localhost, which the public firewall never saw, and changed a target account's email and password.
5. They completed the normal app login, including the email one-time code, and received the same tokens the real app uses.
6. Those tokens gave access to the account's vehicles and remote commands, including door unlock and engine start. They ran vehicle commands only on cars they owned or were allowed to use.

Two more findings are worth your attention. Changing the password and email did not log the owner out of their existing app session, and the account's alerts could be redirected to the researchers' own phone. And the mobile login flow accepted the weaker "plain" form of PKCE. In the Australian systems, administrator credentials for the identity server had been left in app code meant for a test setup. Combined with the US chain, the researchers say they could have sent unlock and start commands to cars in Australia, the US and Canada.

The US testing was in February 2026. The US fix came about two hours after the report, with credentials rotated and the researchers' proof component removed. The Australian fix date is not given.

What to do

1. Find any Apache Felix console or OpenIDM admin interface in your estate and take it off the internet. Remove it from production, or put it behind its own authentication on an internal network. ForgeRock's own hardening guidance says to remove development tools.
2. Change every default credential and alert on any successful login with the old default.
3. Restrict the OpenIDM administrative and managed-user API paths (/openidm/managed/user among them) to internal networks, not only at the public edge. The researchers got in through localhost, which a perimeter firewall does not see.
4. Make the firewall and the web server read paths the same way: reject encoded separators, semicolon path parameters and dot segments, or normalize them identically in both places. Do not rely on an allow-list of paths under a static prefix.
5. Disable or tightly control schedulers and script services that accept inline code, and alert on new OSGi bundles and on creation of schedule or script configurations.
6. Require S256 for PKCE and reject "plain." Invalidate existing sessions and tokens when a password or recovery email changes.
7. For anything that controls a physical device, require extra verification or notify the owner on high-impact commands like unlock and remote start, and alert on new push-token or device registrations.

What is not known

Which automakers. Whether anyone else reached or used this path before it was closed: the write-up does not say. When the Australian systems were fixed. How many other organizations run an OpenIDM console in the same state. We have nothing on that, and an internet scan for it is not something we ran.

How we know, and how we checked

We read The Hacker News report and the technical write-up. We did not reproduce any step, test any system or read the Australian piece beyond the summary. A corpus search found no earlier post of ours on this. We did not run an edge check: it is a deployment flaw on someone else's servers, and our decoys do not emulate OpenIDM. No indicators of compromise are published, so we ingest none.

Sources

Sam Curry and Shubham Shah, ForgeRock identity server write-up, November 7, 2026, and Shubham Shah's piece on the Australian systems. The Hacker News, "Default 'admin:admin' Server Password Helps Researchers Hack Two Automakers, Unlock and Start Cars," November 10, 2026.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com