Car hacking through identity servers: what the research proves

Car hacking research published by Shubham Shah and Sam Curry shows how administrative access to an identity service can become authority over a physical vehicle. The familiar systems are customer records, sign-in sessions and the mobile app's credentials. A car is where the consequences become unusually tangible. Their account gives developers a reason to inspect the services that define the owner their application trusts.

TL;DR

• Both primary writeups appeared on November 7, describing earlier research. Publication and discovery have different dates.
• Curry's US companion reports same-day remediation after disclosure and limits complete account-to-vehicle testing to US accounts and vehicles.
• Shah's Australian July account has a separate scope and leaves its current remediation status unspecified.
• The researchers report owner-equivalent app authority and permissioned physical demonstrations. Model, subscription and active-service conditions still matter.
• The defensive review starts with administrative identity access and ends with a check of what actually happened at the physical endpoint.

Car hacking starts with trusted identity

A connected-car app relies on online services to associate a customer with a garage of vehicles and the commands those vehicles support. Once the customer completes sign-in, the app obtains the credentials its services expect. The service then acts on the account-to-vehicle relationship.

Shah and Curry's US companion describes access to production identity systems handling customer logins for two unnamed automakers. From those systems, the researchers could create valid sessions for customer accounts managed by the affected deployments. For accounts with active connected services, they report the same remote access available through the owner's app.

That relationship explains the developer consequence. A downstream service can correctly validate the credentials presented to it while the upstream identity defining the customer has already been rewritten. Reviewing token acceptance alone leaves the question of who can change the trusted account facts.

For a defensive review, I would draw the authority boundaries before drawing the feature flow. Which system can change the customer record? Which system completes sign-in? Which credentials does the vehicle service accept? Those questions make the role of each component visible without turning the article into an operational exploit walkthrough.

The distinction travels beyond cars. Any application whose permissions depend on an upstream customer record needs to understand who can change that record. The recommendation comes from the reported mechanism; we have not measured how often other products share it.

Read publication, disclosure and test scope separately

The current news event is the publication of the research. Both primary pages show November 7. Curry dates discovery and disclosure to early 2026. Shah's Australian account describes collaboration beginning in July.

These are separate source timelines. A single chronological story that moves from July discovery to an early-year fix would invent a relationship the sources do not establish. Keeping the two accounts attributed is clearer than trying to repair their chronology with assumptions.

Shah's final paragraph claims broader combined command reach in Australia, the United States and Canada. Curry's explicit physical-test limit remains narrower. Directory reach, a claimed capability and a completed physical demonstration are different evidence categories.

We therefore have no basis to identify the redacted manufacturers, call every model vulnerable, describe Canada as a complete-chain physical test, or announce a new worldwide unpatched emergency. The Australian status left unspecified also gives us no basis to say that it remains open.

Administration needs its own review

In the Australian account, Shah describes management interfaces that relied on keys delivered in browser JavaScript. He also reports administrator credentials in a vendor bundle that worked in production. A browser-delivered bundle is an effective way to distribute bytes widely, which is an awkward property for something intended to stay secret.

The US companion describes a different part of the boundary. The edge treated a request path as static content while the identity backend reached an administration console. Security depended on those interpretations agreeing. The administration tooling ultimately allowed code to run inside the identity service and reach customer records behind the public filtering boundary.

This article deliberately leaves out request payloads, encoded paths, credential values, executable commands and the complete operational chain. The explanatory point is the mismatch between layers and the authority of the process behind the edge.

The independently read PingIDM 7.2 production-hardening guide tells operators to remove or protect development and debug tools before production. It also states that authentication for the console is separate from authentication for IDM.

That separate login is easy to miss if a review begins and ends with the consumer authentication journey. An administrative surface can have its own credentials, configuration and exposure. The inventory has to include that surface explicitly. This is versioned documentation, marked no longer maintained; it is useful evidence of the documented hardening boundary, rather than a new vendor response.

A session and an app token have different jobs

The word token can obscure important distinctions. Administrator access controls identity records. A customer session represents a completed sign-in. The mobile app obtains tokens accepted by the services it calls afterward. The researchers' account follows those boundaries until the connected service accepts owner-equivalent access.

The US multi-factor finding also depends on the integrity of the upstream records. The source describes administrative control affecting the login information and the destination for email verification. Completing that journey verified control over the rewritten account facts.

Shah describes a separate Australian authentication misconfiguration that allowed his chain to skip the extra factor. These findings need their regional configuration context. Declaring multi-factor authentication universally broken would discard the detail that makes the report useful.

Keep the extra factor, and review the systems allowed to define its owner and verification route. A defensive account-recovery review should ask which authority can change a contact destination and what other services will trust that change. That is a review question, not an assertion that every recovery flow is vulnerable.

It is also worth naming each credential in the design review by its job. A diagram labelled administrator access, customer session and app authority is easier to reason about than three boxes carrying the same generic token label.

Physical confirmation changed the strength of the evidence

The most useful detail arrives in the US companion's vehicle-command section. The authors explicitly say that an accepted API command did not prove that the car had acted on it. They refreshed vehicle status and confirmed the physical result with the owner beside the vehicle. Shah unlocked and started it, then stopped the engine and locked it again.

That observation takes the report beyond a successful response on a laptop. It also preserves the permission boundary: these were vehicles the researchers owned or were allowed to interact with. We performed no automotive testing for the episode or this article.

The supported capability matters as much as the confirmation method. Curry describes model and subscription dependencies, and accounts with active connected services. Door unlock and remote engine start are among the reported app commands. Neither primary establishes that the chain defeated an immobilizer or allowed someone to drive away.

For a system with physical effects, I would write the outcome test separately from the API test. What response did the service accept? What state did the service subsequently report? What happened at the device itself? This report answered the physical question with an owner-side check. The article does not extend that result to an untested fleet.

A practical defensive review

Start by inventorying the administrative surfaces that can change trusted customer identity. Give each retained console an explicit owner and identify the authentication system protecting it. Remove unused development tools and protect the tools that remain, consistent with the versioned production guidance.

Then review the boundary between edge filtering and backend interpretation. The source describes a case in which those layers disagreed about the request they were handling. A rule at the edge needs to be evaluated alongside the backend's actual interpretation, rather than treated as the final authority simply because it blocked the expected route.

Finally, follow the trusted account facts downstream. List which services consume ownership, contact destinations and completed sign-in state. Identify which upstream authorities can change them. A useful review should leave the team able to explain who can redefine the owner that each service believes.

The defensive reading focuses on protecting the service's authority. The HN discussion includes practical reasons people like remote features, including checking a forgotten lock and warming or cooling a car. Convenience creates a real service responsibility. Customers can reasonably want the feature and expect its authority to be protected.

Verdict: NEEDS REVIEW

I would audit administrative paths into customer identity before trusting them with physical controls. The reported US remediation deserves credit. The publication makes the authority boundary worth reviewing without establishing a current worldwide emergency.

FAQ

Was this discovered on November 7?

That is the publication date on the two primary pages. Curry dates his discovery and disclosure to early 2026. Shah describes Australian research beginning in July. The sources do not supply one reconciled joint timeline.

Were every region and every vehicle physically tested?

Curry explicitly limits complete account-to-vehicle testing to US accounts and vehicles. Shah describes Australian permissioned testing and a broader combined capability claim. The sources do not establish complete physical testing in every region or across every model and subscription.

Does remote engine start prove that someone can drive away?

The primary writeups establish supported app commands and the stated permissioned physical demonstrations. Driving away and immobilizer defeat are not established by those results.

What should developers take from the identity mechanism?

Review who can change the trusted customer record and which downstream services consume it. A valid session can rest on a rewritten upstream identity, so administrative access deserves an explicit place in the authorization review.

Sources

• Shubham Shah — Australian connected-car account
• Shubham Shah and Sam Curry — US companion, scope and disclosure timeline
• Ping Identity — PingIDM 7.2 production hardening
• Hacker News — connected-feature discussion
• Cover portrait: Magistr8, Wikimedia Commons, CC0; cropped, background-masked and resized without generated detail. Sam Curry's official About page corroborates identity. Photograph date unspecified; no endorsement or current-reaction claim. No film/GIF or anime meme is reproduced in this written edition.

Video media credits

The accompanying video uses a ScreenJunkies/GIPHY Jurassic Park caricature, whose native source links to ScreenJunkies, and the Imgflip Pigeon template. Each is a silent excerpt or still of at most two seconds, transformed as fictional process commentary. Neither depicts an actual automaker reaction. Hosting and publisher provenance grant no blanket reuse licence or legal clearance. These assets are not reproduced in this written edition.

---

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Video transcript and primary sources