Glonce

Researchers chain web bugs to unlock and start any car from one unnamed automaker's app

securityThe Glonce editorsHacker News🔥70Glonce rating70Impact55Novelty50Relevance60Surprise65Players25Credibility85

A security researcher writing on shubs.io describes a July collaboration with fellow researcher Sam Curry to probe the connected-car platform of a major automaker, referred to throughout only as "the automaker" and as brand "X". The author had owned the automaker's vehicles for years and bought a new SUV from the brand in 2023, which gave them personal access to the app. The investigation started by decompiling the automaker's Android APK to reconstruct the API calls the app makes when a user remotely unlocks a car, which led to a cluster of subdomains including admintool.redacted-telematics.com.au, an internet-facing internal tool labelled a 'test harness'. Combing through its JavaScript bundle, the pair found that many of its APIs needed no authentication beyond hardcoded API keys sitting in the bundle itself, letting them look up any user account by email. To go further, they built a chain from a car's number plate to its VIN (easy to obtain through Australian state registration lookup sites), from the VIN to a subscriber GUID via an exposed API, and from that GUID to the full account record, including the registered email, on the automaker's identity platform, ForgeRock OpenIDM. The admin tool itself could provision features, add a secondary user to someone's account or generate remote access codes, but none of that gave direct control of a vehicle. For that, the pair spent two weeks studying how the automaker's identity backend issues the consumer auth tokens that, once obtained, let anyone remotely unlock, lock, honk the horn or start a user's car. While sifting more JavaScript bundles, they found a vendor bundle that embedded admin credentials for OpenIDM; though meant for staging, the researchers suspected (and it turned out) that they also worked in production. OpenIDM's sensitive /openidm/ endpoints were otherwise heavily protected by a WAF that blocked direct requests outright. The researchers spent days trying path-traversal tricks through whitelisted paths such as /XUI/ and /UI/, which bypassed the WAF but ran into OpenIDM routing quirks that still blocked the actual endpoints. They then tested WAF coverage against hidden endpoints pulled from the Android app's decompiled code: one, /openidm/endpoint/aaa, was blocked with a 403, but another, /openidm/endpoint/pinService, returned a 404 with no WAF block. Light brute-forcing around that uncovered a getUser endpoint that, combined with the admin credentials, returned a target's password hash, PIN hash, mobile push tokens and personal details such as phone numbers and full names; the passwords were hashed with PBKDF2-SHA512, which made cracking impractical for a quick unlock. Looking for a cleaner path to OpenIDM's managed/user servlet, the researchers fed OpenIDM's source code to an AI tool, GPT 5.6 Sol Ultra, and let it work the WAF-bypass problem for about six hours. It found that, while the prefix /XUI%2f..%2fopenidm/ was blocked, a different encoded prefix, /static%2f..%2fopenidm/, was not covered by the WAF at all and reached OpenIDM's APIs cleanly, something neither researcher had found manually. With that bypass, the pair could send a PATCH request to OpenIDM's managed/user endpoint using the admin credentials to overwrite the password of any user account outright. The automaker's Australian environment carried a further misconfiguration: its multi-factor authentication step could be skipped entirely, letting the researchers request an authentication token from the login endpoint using a Resource Owner Password Credentials grant with the newly-set password. The published account breaks off mid-sentence as the researchers describe exchanging that token for a usable session, before the article's description of the vulnerability's real-world extent, any notification of the automaker, or a fix.

Key facts

  • Starting in July, a researcher and Sam Curry decompiled the automaker's Android app to reconstruct its API calls and find the infrastructure behind remote car unlock.
  • An internet-exposed admin tool had APIs protected by nothing but hardcoded API keys in its JavaScript bundle, letting the researchers look up accounts by email and build a chain from a number plate to a VIN to a subscriber GUID to a user's email via Australian public vehicle lookups.
  • A vendor JavaScript bundle embedded admin credentials for the automaker's ForgeRock OpenIDM identity system, meant for staging but also valid in production.
  • After days of failed manual attempts against a WAF blocking /openidm/* paths, the researchers used an AI tool, GPT 5.6 Sol Ultra, for about six hours to find that the prefix /static%2f..%2fopenidm/ was not covered by the WAF.
  • With that bypass the researchers could overwrite any user's password via OpenIDM, and a misconfiguration in the automaker's Australian environment let multi-factor authentication be skipped entirely, clearing the way to a valid auth token that the author says gives full remote control of a car's unlock/lock, horn and engine.

Why it matters

This is a reminder that connected-car security often comes down to ordinary web application flaws rather than exotic hardware hacking: a chain of a leaky admin tool, hardcoded API keys, exposed identity infrastructure and a WAF bypass added up to full account takeover and remote control of vehicles. It also shows an AI tool succeeding where two experienced human researchers had spent days failing manually, finding a WAF-evading path-traversal prefix after about six hours of work.

Who it affects

Customers of the unnamed automaker whose accounts and vehicles sit on the described platform, with the documented testing specifically against the automaker's Australian environment, including its redacted-telematics.com.au and redacted-identity.com.au infrastructure and Australian number-plate-to-VIN lookups. The account does not name the automaker, the car brand, or the author.

How to use it

For security teams running similar connected-car or IoT backends, the write-up is a checklist of what to audit: decompile your own mobile apps for hardcoded admin API keys and embedded credentials before an attacker does, make sure internal admin tools and identity servers (here, ForgeRock OpenIDM) are not reachable from the open internet at all rather than relying on WAF rules to hide them, and verify that multi-factor authentication cannot be skipped in any regional deployment. For car owners, it is a reason to ask manufacturers how their connected-car identity systems are secured.

How solid is it

The account is a first-person technical write-up by the researcher on their own blog, naming Sam Curry as a collaborator, and it includes specific technical detail such as endpoint paths, HTTP status codes and request/response examples, which lends it credibility. However, the automaker, the car brand and the author's own name are all withheld from the published text, and the available text cuts off mid-sentence during the multi-factor-authentication bypass section, before any discussion of whether the automaker was notified or whether the issues were fixed.

Risks and caveats

No CVE, bug bounty payout or disclosure timeline appears in the available text, and the headline claims the attack works in most of the world, but the available text only documents testing against the automaker's Australian systems. As a single blog post from the researchers involved, it has not been independently verified here, and the available text is truncated, so the full scope of impact is not visible.

“Once you have that auth token, it's pretty much game over. You can control a user's car (remote unlock/lock, horns, engine, etc).”

— the author, shubs.io