News

Researchers Report Remote Vehicle Access Through Connected-Car Login Systems

Security researchers have described how weaknesses in the identity systems behind connected-car apps allowed them to access customer accounts and issue remote vehicle commands during controlled tests. The reported failures involved the systems responsible for managing logins and account permissions, rather than vehicle firmware or a newly discovered vulnerability in the underlying identity software.

Shubham Shah and Sam Curry published their account on 7 November 2026, with their timeline placing the testing and notification of affected organisations earlier in the year. The companies have not been publicly identified, and the researchers said they issued vehicle commands only to cars they owned or had permission to test.

According to the account, the researchers could create valid sessions for customer accounts managed through the affected ForgeRock deployments. Where an account had a linked vehicle with connected services enabled, those sessions reportedly provided access to location information, vehicle telemetry and the same remote locking, unlocking and engine start or stop functions available through the owner’s app.

The capabilities depended on the vehicle and its services, rather than applying uniformly across every model. Digital Today reported that the available functions varied according to the vehicle and whether the owner subscribed to connected services. The disclosure does not establish how many accounts or vehicles were exposed, and the publication reported no confirmed evidence of criminal use.

Two Different Routes Into Customer Accounts

The research described two distinct security failures, both involving the infrastructure supporting connected-car accounts. Although some secondary coverage combined the findings, the reported routes differed in how the researchers reached administrative functions and obtained access to production systems.

The Hacker News described one route involving an OpenIDM administrator console powered by Apache Felix. According to its account, the console was blocked from direct access over the public internet but still used the product’s documented default administrator credentials. A difference in how an edge service and the application server interpreted a web address reportedly allowed the researchers to reach the otherwise restricted interface.

A separate Australian route involved credentials embedded in a vendor JavaScript file distributed with an Android app, according to iTnews. Anyone downloading the app would also receive the file. Although the credentials were associated with a staging environment, the researchers said they also worked against production infrastructure containing live customer records.

The distinction is significant because neither account describes a failure of vehicle hardware. Instead, the reported weaknesses allowed access to the identity infrastructure through which legitimate users obtained vehicle information and issued commands. Once that account layer was compromised, the researchers said they could exercise functions ordinarily reserved for the owner.

iTnews reported that information available through one exposed endpoint included password and PIN hashes, push-notification tokens, phone numbers and full names. It also reported that the researchers could reset a password, bypass multi-factor authentication and generate an authentication token for the app. These were capabilities described in the research, not evidence that criminals had obtained or used the information.

Australian Systems Presented a Separate Exposure

The researchers characterised the Australian route as less difficult to exploit than the North American deployment. According to iTnews, it did not require remote code execution and encountered fewer barriers from the local web application firewall. That comparison reflects their experience with the systems tested, rather than an independent assessment of automotive cybersecurity across either market.

Digital Today reported that the Australian sequence began with a vehicle registration plate, which could be used to obtain its vehicle identification number. The researchers reportedly followed that information to an owner’s account and then demonstrated remote commands. The available reporting does not establish how many vehicles could have been reached through that sequence.

Published accounts identify affected services in Australia, the United States and Canada, but the precise corporate scope remains unclear. Curry’s account refers to two automakers, while iTnews describes one manufacturer behind two brands sold in Australia. The reports do not reconcile those descriptions, and the organisations remain unnamed.

The testing also had geographical and practical limits. According to Curry’s account and The Hacker News, the complete US attack chain was tested only against US accounts and vehicles. The researchers said they refreshed vehicle status after each request and confirmed the physical response on an authorised test car with its owner present.

Those boundaries matter when assessing the findings. The research supports reported account access and vehicle control in the environments tested, but it does not establish that every customer, model or deployment associated with the unnamed companies was affected.

Rapid Fixes, but Questions About Sessions and Alerts

The researchers said the affected deployments were remediated within approximately two hours and that credentials were rotated. iTnews similarly reported that the issue was addressed within hours, although the published accounts do not provide a precise remediation date or identify a fixed software version.

Some observations extended beyond the initial access failures. Repairer Driven News reported that, during an authorised test, the owner’s existing app session remained active after the account’s email address and password were changed. The Hacker News also reported that the researchers could redirect account alerts to their own phone.

These findings suggest that changing credentials and ending existing access may require separate attention. However, they were observations from controlled testing, not findings from a forensic investigation into a malicious incident. The available material does not establish whether the same session and notification behaviour occurred across every deployment or app version.

The Hacker News reported that no CVE identifier or vendor advisory was issued because the weaknesses were attributed to how the companies operated ForgeRock, rather than to a newly discovered flaw in the product. The publication also noted that ForgeRock’s hardening guidance advises operators to remove or protect the Apache Felix console and change its default password.

The absence of a CVE does not diminish the potential consequences of an insecure deployment. In these reported cases, default administrative credentials and staging credentials that worked in production were central to the access described by the researchers.

Identity Controls Become Vehicle Security Controls

For organisations operating connected services, the account highlights the importance of examining how administrative interfaces, development environments and customer sessions are protected. An interface should not depend solely on an edge service or web application firewall to remain inaccessible, particularly when different components may interpret requests differently.

The reported Australian route also underscores the need to keep staging and production credentials separate and to avoid distributing usable secrets in client-side software. Where credentials have been exposed, remediation should include reviewing the access they provided, rotating them and checking whether existing sessions or authentication tokens remain valid.

Session management and notification settings warrant their own scrutiny. A password reset may not end every active session, as the researchers observed in one test, while redirected alerts could affect an owner’s ability to notice account changes. The relevant question is therefore not only whether a password has been changed, but whether all unauthorised access has ended and account communications remain under the owner’s control.

Important details remain unresolved. The number of exposed accounts, the duration of exposure and whether anyone else discovered either route before remediation have not been established. The technical account is self-published, and the available reporting does not describe an independent reproduction of the findings.

The disclosure consequently supports a specific conclusion: weaknesses in particular identity-system deployments reportedly enabled access to connected-car functions during authorised vehicle tests. It does not establish a product-wide ForgeRock vulnerability, a malicious campaign against drivers or universal access to the affected manufacturers’ vehicles.

Understanding those distinctions is an important part of assessing connected-system security. For readers seeking to develop that foundation, The Hack Academy’s online cybersecurity training programme includes cybersecurity fundamentals among its subject areas, combining self-paced theory with practical exercises in controlled, authorised environments.

Leave a Reply

Your email address will not be published. Required fields are marked *