Two automakers left their customer login servers behind a password reading admin. Shubham Shah and Sam Curry found it in early 2026 and finished the chain with owner-level control of parked cars.
The pair pulled apart the Android versions of both apps and traced the authentication traffic back to the same vendor: ForgeRock. One brand ran a sign-in journey called MobileAppSignIn, the other AppSignIn_v2, but both sat on the same consumer realm and the same OAuth client.
Where the firewall stopped working
ForgeRock’s Identity Management component runs Java services inside Apache Felix, and its web console normally sits at a path an attacker would try first. Requests to the sensitive routes hit a web application firewall and got the researchers’ address blocked.
Changing the query encoding, the HTTP method and the path separators produced different responses, and static files still reached the /static endpoint. That gap let them build a URL the filter read as an image path while it resolved to the identity administration panel.
The documented default admin:admin login worked. From there a scheduled task ran their code, planting a servlet that inherited the working directory of the production identity process.
What an owner session could reach
With a real customer login, the researchers read VINs, location, mileage, battery or fuel range, tire pressure, door state and subscription tier. They also sent the same remote commands the official app sends, and confirmed the physical result with the owner standing beside the car.
Both companies patched in about two hours and rotated the affected credentials. The systems served customers in several regions.
Shah’s Australian writeup is the shorter path: a vendor JavaScript bundle carried staging admin keys, and a number plate led through a VIN lookup to a subscriber record. Neither researcher named the brands.
