Two researchers took over the login systems behind two car brands' mobile apps, and from there they unlocked doors and started engines.

The entry point was not a novel exploit. It was a default password on an administrator console that the vendor's own hardening guide tells operators to remove before going live.

Shubham Shah and Sam Curry published their work late last week. They tested the full chain only on their own and consenting owners' cars in the United States, in February 2026. Both systems were fixed about two hours after they reported the problem.

The Architecture Behind the Mistake

Both brands signed customers in through ForgeRock, an identity platform now part of Ping Identity. That platform runs in two parts.

OpenIDM ships with a built-in administrator console powered by Apache Felix. ForgeRock's hardening guide explicitly tells operators to remove this console or protect it before going live, because it stores its own password separately from the rest of the system.

On these servers, the console was still there. And it still used the documented default: admin for both the username and the password.

The Path Confusion Trick

The console was blocked from the open internet. That should have been enough.

But the edge that guards the site and the Java software behind it read the same web address differently. By adding encoded slashes and extra characters, the researchers made the edge treat the request as a harmless static file, while the server treated it as the path to the console.

That mismatch is the entire bypass. No zero-day in ForgeRock. No vulnerability in Apache Felix. Just two components disagreeing about what a URL means.

The default password did the rest.

From Console to Command Prompt

Inside the console, the researchers used a built-in scheduler to run small scripts that execute their own code on the identity server.

That gave them a command prompt on the machine holding the customer records for both brands' logins.

The records sat behind the same block as the console. The researchers' code reached them from inside the server, which is exactly why perimeter controls did not help.

The Account Takeover

With access to the records, the researchers changed a target account's email address and password.

Then they signed in as that customer through the normal app. The app returned the same access tokens a legitimate user would receive.

Those tokens were the keys to the car. Using the account's own vehicle commands, the researchers unlocked the doors and started the engine of a test car, with the owner standing next to it. Then they stopped the engine and locked it again.

What They Did and Did Not Demonstrate

The researchers were precise about the boundary of their claims.

They reported being able to open a session for any customer account on the affected servers. They ran vehicle commands only on cars they owned or were explicitly allowed to use. And they stated they tested the complete chain only with US accounts and vehicles.

That is the right way to publish this kind of research. The account takeover capability is general. The physical demonstration was limited to consented targets.

The Australian Chain

Shah published a second attack on the Australian systems behind the same brands. The entry point there was different.

Admin credentials for the identity server had been left in the app's code, intended for a test setup. He documented the full Australia chain in a separate post.

Taken together, the researchers said they could send unlock and engine-start commands to the brands' cars in Australia, the United States, and Canada. The second post does not give a date for when the Australian systems were fixed.

Why Owners Would Not Notice

The attack left almost nothing for an owner to detect.

Changing the email and password did not log the owner out of their app. The researchers could direct the account's alerts to their own phone, keeping them off the owner's device.

They put the real email address back after the test. Neither write-up says whether anyone else found or used the path before it was closed.

That silence is worth sitting with. The window existed. Whether it was used by someone else is unknown.

What Identity Teams Should Check

The brands' mistake was in how they operated ForgeRock, not in the product itself. That means there is no CVE, no vendor advisory, and no patch to install. The console and its default password have been documented for years.

For teams running the same identity software, now sold as PingIDM, two checks matter.

• Look for the Apache Felix console at /system/console. Remove it, or change its default password. The hardening guide already tells you to do this.
• Do not count on edge or WAF path rules to hide an admin page. A path the edge and the server read differently can slip past the rules, as it did here.

That second point is the generalizable lesson. Path-based blocking assumes every layer in the stack parses the URL the same way. When they do not, the block is decorative.

The Pattern

Shah and Curry have a long record of this kind of work. They usually break into the web systems behind the apps, not the cars themselves.

They have demonstrated remote access to vehicles from Honda, Kia, and Subaru, among others. A Subaru flaw they reported exposed owners' accounts and their cars through the manufacturer's connected-car service. A broader 16-brand study in 2023 found the same class of web weakness across much of the industry.

The cars are not the problem. The identity layer underneath them is, and it keeps being configured the same way.

FAQ

What did the researchers actually exploit?

A default password on an Apache Felix administrator console inside ForgeRock's OpenIDM component. They reached the console by making the edge and the server parse the same URL differently, using encoded slashes and extra characters.

Was this a vulnerability in ForgeRock?

No. It was a configuration failure. ForgeRock's own hardening guide tells operators to remove the console or protect it before going live. There is no CVE and no vendor advisory.

How did they get from account access to unlocking a car?

They changed a target account's email and password, signed in through the normal app, and received the same access tokens a legitimate user gets. Those tokens authorized the vehicle commands.

Did they unlock real cars?

Yes, but only their own and consenting owners' cars in the United States in February 2026. They reported being able to open a session for any customer account, but ran vehicle commands only on cars they were permitted to use.

What is the Australian attack?

A second chain where admin credentials for the identity server had been left in the app's code, intended for a test setup. Shah published it separately.

Was the attack noticeable to owners?

Barely. Changing the email and password did not log the owner out of the app, and the researchers could redirect account alerts to their own phone.

How fast were the systems fixed?

About two hours after the researchers reported the problem.

What should identity teams do?

Check for the Apache Felix console at /system/console and remove it or change its default password. Do not rely on edge or WAF path rules to protect an admin page.

Is this related to previous car research?

Yes. The same researchers have demonstrated remote access to Honda, Kia, and Subaru vehicles, and a 2023 study found the same class of web weakness across 16 brands.

Source: The Hacker News