Default admin

The login systems behind two car brands' mobile apps could be taken over completely through an identity server admin console that still accepted the default username and password admin:admin. Security researchers Shubham Shah and Sam Curry used it to reach any customer account on the affected servers. On test cars, with the owners' consent, they unlocked the doors and started the engine remotely. Both systems were fixed about two hours after the researchers reported the problem in February 2026. The research was published in early November.

There is no CVE and no vendor advisory. The product had no new bug. The failure was in deployment: a default password that has been documented for years, left in place behind an edge filter that did not read URLs the same way the backend did.

The Stack: ForgeRock, OpenIDM and the Felix Console

Both brands signed customers in through ForgeRock, an identity platform now part of Ping Identity. Its identity management component is sold today as PingIDM. The platform runs in two parts: one handles login, and OpenIDM holds customer records. OpenIDM ships with an admin console built on Apache Felix, served at /system/console.

ForgeRock's production hardening guide tells operators to remove that console or protect it before going live, because it keeps its own password separate from the rest of the platform. On both brands' servers the console was still deployed and still used the documented default: admin for the username and admin for the password.

The Attack Chain

The console was blocked from the open internet. The researchers got around the block with a parser mismatch: the edge that guards the site and the Java application server behind it interpreted the same web address differently.

• Path confusion: encoded slashes and extra characters made the edge treat the request as a harmless static file, while the Java server resolved it to the Felix console.
• Default credentials: admin:admin authenticated to the console.
• Code execution: the console's built-in scheduler ran small scripts, giving the researchers a command prompt on the OpenIDM server that holds customer records for both brands.
• Account takeover: customer records sat behind the same edge block, but code running inside the server reached them directly. The researchers changed a target account's email address and password.
• Token issuance: they signed in as that customer through the normal mobile app and received the same access tokens the real app uses.
• Vehicle commands: using the account's own vehicle commands, they unlocked a test car and started its engine with the owner standing beside it, then stopped the engine and locked it again.

A Second Way In: Australia

Shah published a separate attack on the Australian systems behind the same brands. The entry point was different: admin credentials for the identity server had been left in the mobile app's code, apparently meant for a test setup. With both attacks combined, the researchers said they could send unlock and engine start commands to the brands' cars in the United States, Canada and Australia. The Australia write-up does not say when those systems were fixed.

Scope and Limits

The researchers 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 had permission to use, and said they tested the complete chain only with US accounts and vehicles. They restored the real email address after testing. Neither write-up says whether anyone else found or used the path before it was closed.

Why This Matters Beyond Automotive

The car is the dramatic endpoint, but this was an identity infrastructure failure. One identity server held customer records for two brands, so a single console compromise reached both. Customer identity platforms now act as the control plane for physical devices: cars, smart locks, building systems, medical devices. Whoever controls an account's email and password controls the device attached to it.

Two patterns here show up again and again. First, vendor admin interfaces with their own credential stores tend to fall outside normal password rotation, SSO and monitoring. The Felix console's separate password is exactly that kind of blind spot. Second, edge and WAF path rules are not access control. When the proxy and the origin server normalize paths differently, encoded characters get through. Path normalization and request parsing mismatches have defeated this pattern many times before, across many products.

The Researchers' Track Record

Shah and Curry have a long record of this work, usually breaking into the web systems behind connected-car apps rather than the vehicles themselves. They have shown remote access to vehicles from Honda, Kia and Subaru, among others. A Subaru flaw they reported exposed owners' accounts and their cars through that carmaker's connected-car service. A 2023 study they took part in covered 16 brands and found the same class of web weakness across much of the industry. This latest finding shows the pattern continuing: the vehicle's own security can be solid while the cloud identity layer that issues its commands is left exposed.

RedEye Assessment

A two hour fix is fast, and both automakers deserve credit for it. But the exposure came from a default that the vendor's own hardening guide flags, sitting in production for an unknown length of time. Organizations whose identity platform issues tokens that control physical assets should treat that platform's admin surfaces, credential stores and edge parsing behavior as critical attack surface. The test should be what an attacker can actually reach, not what the WAF rules say should be blocked.