Default ForgeRock Password Opened Car Apps

The most consequential weakness in two automakers' connected-car platforms was not a memory bug or a novel cryptographic break. It was a console that should have been deleted before launch, still answering to the word admin for both username and password. Two security researchers found the console behind the mobile apps of two car brands, used it to change a customer's credentials, and then sent the same unlock and engine-start commands the app would send.

The work was published by Shubham Shah and Sam Curry, who reported the issue to the brands and say both systems were fixed roughly two hours after disclosure. Testing of the full vehicle chain was limited to the researchers' own cars and those of consenting owners in the United States, and was carried out in February 2026.

The shared login backend

Neither app was attacked directly. Both brands routed customer sign-in through ForgeRock, an identity platform now part of Ping Identity. That platform runs in two pieces from the operators' point of view: one handles login, and a second component, called OpenIDM, stores the customer records that the login layer depends on.

OpenIDM ships with an administrative console built on the Apache Felix tool. The console is a known quantity. ForgeRock's own documentation tells operators to remove it or otherwise protect it before exposing a deployment, because it keeps its password in a separate store from the rest of the system. On the servers behind these two apps, the console had not been removed, and its credentials were still the documented pair: admin and admin.

According to the researchers' write-up, reaching the console from the public internet was blocked. That block did not hold.

Two systems, one web address

The obstacle was not a firewall rule but a disagreement about what a URL means. The edge layer in front of the site and the Java application behind it parsed the same address differently. By adding encoded slashes and extra characters to the path, the researchers got the edge to classify the request as a request for a harmless static file, while the origin server resolved it as the path to the administrative console.

The console then asked for credentials, and the defaults worked. The full method is set out in the researchers' technical analysis.

Once inside, they did not need to exploit anything else. The console includes a built-in scheduler capable of running small scripts, which the researchers used to execute their own code on the identity server itself. That produced a command prompt on the machine holding the customer records for both brands' logins.

From console to a customer's session

The customer records were protected by the same edge rule that was supposed to shield the console. The researchers' code did not need to go through the edge at all; it reached the records from inside the server, where the rule did not apply.

What followed was a straightforward account takeover performed through supported features. The researchers changed a target account's email address and password, then signed in as that customer through the normal mobile app. The app issued the same access tokens it would issue to the real owner.

Those tokens carried the account's vehicle permissions. Using the account's own commands, the researchers unlocked the doors and started the engine of a test car while the owner stood beside it, then shut the engine down and locked the car again.

The scope of what they demonstrated was deliberate. They reported being able to open a session for any customer account on the affected servers, but they ran vehicle commands only on cars they owned or had explicit permission to use. Their stated limit: they "tested the complete chain only with US accounts and vehicles."

The quieter Australian path

A second write-up from Shah describes a different route into the Australian systems behind the same brands. There, the entry point was not a console left on defaults but administrative credentials for the identity server left inside the app's own code, apparently intended for a test environment. He laid out that Australia chain in a separate post.

Taken together, the two researchers said the attacks allowed them to send unlock and engine-start commands to the brands' cars in Australia, the United States, and Canada. The Australian post does not state when those systems were fixed.

The US-side write-up does not describe any similar embedded-credential problem; the two chains are distinct, and the researchers present them as separate pieces of work rather than a single exploit.

An intrusion the owner would not see

The attack was designed to leave no obvious trace for the person whose account was used. Changing the email address and password on an account did not log the owner out of the app on their phone, so the session continued as normal.

The researchers also found they could redirect the account's alerts to their own phone, keeping notifications off the owner's device. That combination means an owner would have had no prompt to check anything, and no obvious record afterward.

After testing, the researchers restored the real email address on the account they had modified. Neither write-up says whether anyone else discovered or used the same path before the fix went in.

No CVE, because nothing was patched

There is no CVE identifier and no vendor advisory attached to this work, and that absence is itself the point. The researchers describe the failure as a deployment mistake, not a software vulnerability: the identity product behaved as documented, and the operators left an administrative interface in place with its default credentials.

The console and its default password have been documented for years, and the vendor's production hardening guide already instructs operators to remove the console or change its password before going live. Because the fix is configuration rather than a code patch, the normal machinery of advisories, scanners, and patch windows never engaged.

That also means there is no public list of other deployments that share the exposure. The researchers' finding is specific to the servers they examined; the source material does not say how widely the same configuration exists elsewhere.

What identity teams should check

For organizations running the same identity software, now sold as PingIDM, the researchers' write-up narrows to two concrete checks.

• Look for the Apache Felix console at /system/console, and either remove it or change its default password.
• Do not rely on edge or WAF path rules to hide an administrative page. A path that the edge and the origin server parse differently can pass straight through those rules, as it did in this case.

The second point is the one that breaks the usual mental model. A WAF rule is often treated as a compensating control when an internal interface cannot be taken offline quickly. Here the rule was present and the interface was still reachable, because the control and the protected system disagreed about what the request was.

The researchers' broader point is that the exposure did not require a flaw in ForgeRock itself. The console is a shipped feature with a documented default; the hardening guide is public; the operator simply did not follow it.

A familiar target for the same pair

Shah and Curry have a track record in exactly this layer of the stack: the web services that sit behind vehicle mobile apps, rather than the vehicles' internal electronics. They have previously demonstrated remote access to cars from Honda, Kia, and Subaru, among others.

A Subaru flaw they reported exposed owner accounts and, through the carmaker's connected-car service, the cars themselves. An earlier 16-brand study in 2023 found the same class of web weakness across much of the industry.

The through-line across those findings is not a particular vendor or component. It is that the account behind a connected car is a credential like any other, and the systems that issue it are built and operated with the same shortcuts as any other web application.

Why the deployment layer matters most

For security teams, the uncomfortable lesson here is that the control that failed was not exotic. A default credential on an administrative console, and a URL-parsing mismatch between an edge and an origin, are both well-understood problems with well-understood fixes. What made them dangerous was that they sat in front of an identity provider holding the keys to physical access.

That combination suggests identity infrastructure deserves the same scrutiny as the vehicles it controls. If the login service can mint a token that unlocks a door, then the login service is, functionally, part of the car's security perimeter — and a console left on admin:admin is a lock on that perimeter.

For vehicle owners, the practical exposure is limited in what the researchers documented: the affected systems were fixed about two hours after they were reported, and the write-ups do not describe evidence of prior exploitation. But the mechanics show how little an owner could have done. There was no phishing link to avoid and no password to strengthen; the account was changed from the inside, the session stayed live, and the alerts went elsewhere.

For the industry, the finding points at a gap between how identity platforms are marketed and how they are operated. Hardening guidance exists, and in this case it was specific enough to name the exact console at the exact path. Whether other deployments have followed it is not something either write-up can answer — but the same misconfiguration would be invisible to a customer and quiet in an owner's app, which suggests operators should check rather than assume.