Two well-known researchers showed they could hijack any customer account at two car brands and then unlock and start the vehicles, all through the identity platform behind the owners’ apps. The carmakers closed the hole within about two hours of the report, but according to iTnews the researchers received neither a bounty nor public credit.
What happened
On 7 November 2026 Sam Curry and Shubham Shah, the Sydney-based co-founder of Assetnote, published the technical write-up of research they carried out earlier this year against the customer login systems of two automakers. Both brands ran their app sign-in and customer records on ForgeRock’s identity stack, which is now part of Ping Identity and sold as PingIDM. For owners with connected services switched on, that meant the same powers as the official app: vehicle location and telemetry, door unlock and lock, and remote engine start and stop.
The pair ran the full chain against US accounts and vehicles, limiting vehicle commands to cars they were authorised to use, with a test vehicle unlocked and started while its owner stood beside it. Shah published a companion post describing a different route into the same carmaker’s Australian systems. Taken together, the write-ups cover vehicles in Australia, the United States and Canada.
Curry’s disclosure timeline says both manufacturers fixed the issue roughly two hours after receiving the report and rotated the affected credentials. Both asked not to be named; Curry agreed rather than see them “diverting resources” at a busy time. iTnews reports that the carmaker gave the pair no bug bounty or recognition of any kind. Infosecurity Magazine notes that Shah’s Australian post gives no report or fix date, and neither write-up reports malicious use.
The technical picture
There is no new software flaw here, so no CVE and no vendor advisory: this is about deployment and hardening.
On the US systems, OpenIDM, the component that holds customer records, shipped with an Apache Felix web console for OSGi administration. ForgeRock’s own production hardening guidance tells operators to remove that console or protect it before go-live, because it keeps its own credentials separate from the rest of the platform. Here it was still present and still accepted its documented factory default login. The console was meant to be unreachable from the internet, but the edge infrastructure and the Java application server behind it interpreted specially encoded paths differently. A request the edge treated as a harmless static file reached the admin console on the server. Built-in scheduling features then let the researchers run code on the identity servers, alter a target account’s email and password, and sign in through the normal app to collect genuine tokens.
In Australia the route was simpler. Administrator credentials for OpenIDM, nominally scoped to a staging environment, were bundled in a vendor JavaScript file within the customer Android app, and they worked against production. Starting from a number plate, which led to the vehicle identification number, the researchers could reach exposed endpoints returning names, phone numbers, push tokens and password and PIN hashes, reset passwords and sidestep the multi-factor step. According to iTnews, the Australian firewall was weaker, so remote code execution was not needed there. Shah’s own write-up says the US effort “required a lot more work” because the carmaker had secured its US, Canadian and European environments more heavily.
Two details should worry defenders. Resetting the login details left the genuine owner’s session intact, and alerts could be rerouted to a different handset, so a real attacker could have stayed quiet for some time.
Why it matters for UK organisations
The researchers tested the full chain only in the US and described a separate chain in Australia, so nothing here shows that UK drivers were directly exposed. Shah’s own comment that the carmaker ran separately secured European environments is a reminder that one global brand can run several regional deployments with very different security standards. That inconsistency is exactly what the researchers exploited in Australia.
The lesson travels well beyond cars. Any UK organisation running a customer identity platform, from retailers and banks to energy suppliers and public bodies, faces the same risks: admin interfaces left in place, test credentials shipped in client code, and edge filtering used to hide pages that should never be reachable. Because customer identity is the front door, a slip there becomes account takeover at scale.
There is also a disclosure point for the Bug Bounty community. The fix was fast, but the researchers were reportedly paid nothing and the companies stayed anonymous. UK firms that run connected products or large consumer platforms should ask whether their own process would reward and credit a report like this, or whether a finder would have to rely on goodwill.
Expert view
A two-hour fix is genuinely impressive. In my experience, getting a large enterprise to change a production identity platform the same day is rare, and it shows the product security teams took the report seriously.
The bounty question is harder to defend. These were not marginal findings dressed up as critical. They gave fully remote control of customer vehicles and access to personal data, and the researchers stuck to cars they were authorised to use. If iTnews’s account is right, offering nothing for work of that quality signals to the research community that finders should take their time elsewhere, and less scrupulous ones may conclude such access is worth more on other markets. A vulnerability disclosure policy with no reward is better than nothing, but for a manufacturer whose products can be unlocked remotely, a properly funded programme looks like cheap insurance.
When we test identity platforms, default consoles and parsing mismatches slip through because each team assumes another layer covers them.
What to do now
- Hunt for leftover admin consoles. If you run ForgeRock or PingIDM, check whether the Apache Felix web console is deployed, and remove it or change its credentials, as the vendor’s hardening guidance advises. This maps directly to the Cyber Essentials secure configuration control on default passwords and unnecessary services.
- Audit client-side code for secrets. Scan shipped mobile apps and JavaScript bundles for credentials, and rotate anything found immediately.
- Separate staging from production. Make sure test credentials cannot authenticate against live directories. Enforce this in the platform, not by convention.
- Stop relying on edge path rules to hide admin pages. Restrict administrative interfaces by network location and strong authentication, and test for path parsing differences between your edge and your application servers.
- Tighten account change controls. Revoke existing sessions and notify the old address whenever an account’s email or password changes, and ensure multi-factor checks cannot be skipped through alternative OAuth grant types.
- Review your disclosure and reward process. Publish a clear vulnerability disclosure policy, decide in advance how you will reward high-impact reports, and make sure researchers get credited when they want to be.
Bottom line
Default credentials and test secrets in production let two researchers take over owner accounts and start cars remotely. The carmakers fixed it in hours, which shows they could act fast. Reportedly paying nothing for the report sends the wrong message to the people best placed to find the next one.
Sources
- Sam Curry: Hacking Two Automakers: ForgeRock Path Confusion, RCE, and Remote Vehicle Access
- The Register: Researchers pwn automakers’ Android apps to remotely unlock cars, honk horns
- The Hacker News: Default ‘admin:admin’ Server Password Helps Researchers Hack Two Automakers, Unlock and Start Cars
- Infosecurity Magazine: Default Admin Password Let Researchers Unlock and Start Cars
- iTnews: Admin creds left in carmaker app opened doors to vehicles
