# How a connected car's login system became a door key

**Summary:** Shubham Shah and Sam Curry opened connected cars through cloud account takeovers. Their reports show why every route to an app login token matters, while leaving full vehicle and regional coverage unverified.

- Canonical: https://markhuang.ai/news/connected-car-cloud-account-unlock
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-11-09
- Section: News
- Tags: Connected Cars, Cybersecurity, Account Takeover, ForgeRock, Vehicle Security
- Source: [Shubham Shah](https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![A sculpted cloud holds a brass key beside the driver's door of a blue SUV](https://cdn.markhuang.ai/news/connected-car-cloud-account-unlock/hero.webp)

*Conceptual illustration: a connected car's cloud account can authorize actions at the vehicle. This artwork does not depict the researchers' test.*

Shubham Shah and Sam Curry sent an unlock command to a car they had permission to test, and its doors opened. Their route ran through the manufacturer's online account systems. In [Shah's November 7, 2026 writeup](https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/), the Australian chain began with a license plate and ended with a login credential accepted by the car's normal remote-command service.

The result made a familiar convenience available through an account takeover. The researchers could obtain the digital authority that the owner's app uses to send commands. The doors' security therefore depended partly on who could change an online account and obtain a working login.

The limits matter. Both researchers describe authorized testing. The manufacturer remains unnamed, and the available features depend on the connected vehicle and service. [Their companion report](https://samcurry.net/forgerock) says its two unnamed automakers fixed that reported vulnerability within about two hours of receiving it and rotated the affected credentials. Shah's Australian writeup gives no separate remediation timeline.

## The lookup connected a car to its owner

Shah started by tracing the services behind the manufacturer's Android app. That led to an online administration tool whose publicly delivered JavaScript contained API keys. The researchers report that several of its APIs, the interfaces software uses to request data or actions, required no authentication beyond those exposed keys.

They could connect a vehicle identification number, or VIN, to a subscriber record and then an owner's email address. Shah explains that Australian registration lookups could supply the VIN from a license plate. A VIN is an identifier with legitimate uses, including checking a used car's history. The failure was in what the online services allowed someone to retrieve using it.

Those lookups still did not let Shah and Curry unlock a car. The administration tool had extensive account-management functions, but Shah explicitly says they did not yield remote control. Identifying the owner and gaining authority to act as the owner were separate problems.

The next discovery connected them. A different JavaScript bundle contained administrator credentials for ForgeRock OpenIDM, the software managing customer identities. Credentials intended for a staging environment also worked in production, according to Shah.

## A second login path skipped the extra check

A web application firewall stood in front of the identity system. This kind of filter inspects incoming requests and blocks selected traffic. The researchers encountered real obstacles, but eventually found a request-path variation that reached the protected account-management functions. With the exposed administrator credentials, they could replace a customer's password.

The app's multi-factor authentication added another check beyond a password. Shah reports that the Australian deployment also allowed an alternate authentication route that skipped that check. The route used the Resource Owner Password Credentials grant, an OAuth login mechanism, followed by exchanges that produced the access token used by the mobile app. An access token is the digital credential a service accepts when the app makes subsequent requests.

This was a deployment failure with a concrete consequence: after changing the account's password, the researchers could obtain a token without completing the app's normal multi-factor flow. They then used that token to send the unlock command.

The [OAuth security guidance in RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.4) says the password credentials grant "MUST NOT" be used and explains that it is not designed for two-factor authentication or authentication involving multiple user interactions. That guidance helps explain why a reassuring check in the usual login screen cannot establish the security of every route to an app token.

The Australian sequence, simplified from Shah's report, was:

```mermaid
flowchart TD
  A["License plate and VIN lookup"] --> B["Exposed APIs reveal the linked customer account"]
  C["Exposed administrator credentials and a firewall bypass"] --> D["Replace the account password"]
  B --> D
  D --> E["Alternate login skips the extra authentication check"]
  E --> F["Obtain a mobile app access token"]
  F --> G["Send an unlock command through the normal remote service"]
```

## What "any car" leaves out

Shah's headline makes a broad claim, and his conclusion names Australia, the United States and Canada. The companion report is more specific about its evidence: the researchers accessed production identity directories across multiple regions, but tested the complete account-to-vehicle chain only with US accounts and vehicles. It also says supported remote functions depend on the model and subscription.

I read that as evidence of a serious failure in the affected connected services. It does not establish that every vehicle the manufacturers ever sold was reachable. The [Hacker News discussion](https://news.ycombinator.com/item?id=50419215) includes a reader questioning the "any car" wording for older cars. The distinction is already supported by the companion report's connected-service conditions; commenters' guesses about the manufacturer add no verification.

The demonstrated outcome also needs a boundary. The companion report describes physical confirmation with an owner beside the vehicle: unlock and engine start, followed by engine stop and locking. These reports do not demonstrate control of steering or brakes, or that a vehicle could be driven away.

## The account belongs in the car's security review

In [September 2024, WIRED reported on a separate Kia web-portal flaw](https://www.wired.com/story/kia-web-vulnerability-vehicle-hack-track/) that let researchers reassign access to connected-car functions. WIRED observed a demonstration. That earlier case supplies context for the type of failure here; it does not identify the unnamed manufacturers in the new reports.

The question I would put to a connected-service provider is whether every way of changing an account or issuing an app token enforces the intended protections. Reviewing only the normal app login would have missed the Australian route Shah describes. The researchers' success depended on failures across administration, identity management and authentication.

For owners, the unnamed vendors and absent model list limit any vehicle-specific advice. An online account can carry authority to open a physical door. For a security review, that means checking who can edit the account and issue its login tokens, alongside checking the app that displays the unlock button.