ForgeRock connected-car flaws: researchers unlock cars via identity-platform bugs, no CVE

Two security researchers published write-ups on 7 November 2026 showing how weaknesses in the ForgeRock-based login systems of connected-car apps could let an attacker take over a customer account and then send commands to the owner's vehicle, such as unlocking the doors. Shubham Shah of Assetnote says a chain starting from an Australian number plate was enough to unlock a car; Sam Curry describes a separate chain on two automakers' identity platforms that ended in remote vehicle access in the US. Neither post names the automakers, and neither lists a CVE.

Key points

• Shubham Shah's post (dated 7 November 2026) describes a roughly seven-step chain from an Australian number plate to a remote door unlock, built on hardcoded admin credentials, a firewall bypass and an MFA step that could be skipped.
• Sam Curry's post of the same date, "Hacking Two Automakers: ForgeRock Path Confusion, RCE, and Remote Vehicle Access", describes code execution on the identity servers of two unnamed automakers, followed by account takeover and vehicle commands.
• Curry says both automakers fixed the issue about two hours after he reported it and rotated credentials; Shah's post does not say when or whether his chain was fixed.
• Neither post names the automakers, and no CVE is listed in either.
• Both chains rely on ForgeRock OpenIDM (identity management software) sitting behind a web application firewall (WAF) that could be bypassed with path tricks.

What to do

• Car owners: nothing to install. The vulnerabilities were in the carmakers' back-end systems, not in the cars or phone apps themselves, and according to Curry the two automakers he tested have fixed theirs. Because the brands are not named, we cannot tell readers whether their car was in scope.
• Teams running ForgeRock OpenIDM or similar identity platforms: check that administrative paths such as /openidm/ and any OSGi (Felix) web console are not reachable from the internet, including through encoded or traversal paths that a front-end firewall may not normalise the way the back end does. Change default credentials, and make sure no admin credentials are embedded in JavaScript shipped to clients. These are our general recommendations drawn from the two chains, not an official vendor advisory.
• To check exposure: from outside your network, request your identity platform's admin and console paths with encoded variants and confirm every one is refused.

What happened

Shah, writing for Assetnote, says the work was done in July 2026, with about two weeks spent on the identity platform of an unnamed automaker's connected-car service in Australia. His post says it covers vehicles across both of the automaker's brands, and that a related chain also worked in the US and Canada, which Curry's companion post covers. He writes that Europe was more heavily secured. The researchers say they used the chain only on cars they owned or had permission to access.

The chain, as Shah describes it:

1. A number plate can be turned into a VIN (vehicle identification number) through public state registration lookups. An internal admin tool then mapped the VIN to a subscriber ID and the account's email address, using hardcoded API keys found in the app's JavaScript.
2. A vendor JavaScript bundle contained admin credentials for the identity system's OpenIDM instance. The researchers believed they were meant for staging but they also worked in production.
3. An Nginx firewall blocked the sensitive /openidm/ paths, but path traversal through an allowed prefix got around it.
4. With admin access they could overwrite any user's password through the OpenIDM API, and a custom endpoint returned password hashes (PBKDF2-SHA512), PINs, push tokens and personal data.
5. In the Australian environment the multi-factor step could be skipped, so the researchers minted a valid app access token for any user using standard OAuth flows.
6. That token authorised the vehicle command API, which unlocked the car.

Curry's post describes a different chain on two unnamed automakers, "Automaker #1" and "Automaker #2", both on ForgeRock-based login platforms; he says he was asked not to name them. A firewall rule set blocked administrative paths, but path-encoding tricks reached a hidden OSGi (Apache Felix) web console that still had default credentials. The console let him create a scheduled job that ran Groovy code inside the identity server and installed a command-execution component. From there he reached the directory's local admin API, which the public firewall blocked, and could read and modify customer records. He changed a test customer's email and password, completed the normal mobile login with an emailed one-time code, exchanged the session for the mobile app's OAuth tokens, listed the account's vehicles and sent commands.

He says the commands supported included door lock and unlock and remote engine start and stop, that he confirmed unlock and engine start and stop with the owner present, and that he registered a push token he controlled so the owner's phone would not get notifications. The post says the full chain was tested only with US accounts and vehicles, though the platforms served consumers in several regions. According to his post, the Felix console reported version 7.0.1 with 361 bundles, 343 of them active.

Background

Connected-car platforms put a cloud account between a phone and a car, so a flaw in the account system becomes a flaw in the car's remote controls. Curry and Shah have found this class of bug before: the Register covered a 2022 SiriusXM connected-car flaw that, per the researcher's account, allowed door unlocks and engine starts knowing only the VIN, and earlier write-ups described weaknesses in Subaru's Starlink service (where a car was unlocked from a licence plate) and in Kia vehicles. Those earlier results are why a plate-to-unlock chain is a plausible attack path and not a new kind of problem.

What is new in these two write-ups is the common component. Both rely on the same identity product in front of consumer accounts, and both beat a firewall that was meant to hide its administrative interface. That points to a shared lesson rather than a single vendor's mistake.

How it works

The firewall was configured to block requests whose path starts with an administrative prefix. Shah describes path traversal through an allowed prefix and Curry describes path-encoding tricks. Both are consistent with the firewall and the back-end server reading the same path differently, so a request that passed the firewall resolved to a blocked admin endpoint (the posts give the exact paths; we have not reproduced this). Once behind it, default or embedded credentials did the rest. After the identity system was compromised, the car's own security no longer mattered, because the car trusts what the account system says.

What it means

Automakers and identity vendors: the weak points were old, well-known mistakes (default credentials, secrets in client-side code, a firewall relied on as the only barrier) in a system that controls a physical product. Curry's two-hour fix time shows these can be closed quickly when reported, which also shows how long they might otherwise have stayed open.

Owners: the practical risk after a fix is low, but it is worth knowing that a number plate alone was, in one researcher's account, enough to start an attack. Shah's chain began with data that is public by design.

What we don't know yet

• Which automakers were involved. Both posts withhold the names, so we cannot say whether Shah's chain and Curry's are the same companies.
• Whether Shah's Australian chain has been fixed. His post, as we read it, does not give disclosure or fix dates.
• Whether any attacker used these flaws before the researchers. Neither post says.
• Whether other ForgeRock customers had the same exposure. We found no vendor advisory or independent coverage of either post in our searches, so everything here rests on the researchers' own accounts.
• The two posts differ on timing: Shah says testing took place in July 2026, while Curry's transcript timestamps are from February 2026 and the posts were published together.

What to watch next

Watch for the automakers or ForgeRock's maintainers to comment, for any advisory with a CVE, and for the researchers' follow-ups. Security teams should also expect more scrutiny of identity platforms placed behind firewalls, since both chains broke at that seam.

Sources

• Unlocking any car from X brand in most of the world, Shubham Shah, 7 November 2026 (primary)
• Hacking Two Automakers: ForgeRock Path Confusion, RCE, and Remote Vehicle Access, Sam Curry, 7 November 2026
• Subaru Starlink admin panel flaw, earlier Curry and Shah research (Motorbiscuit)
• Connected-car hacking research, The Register, 2022