Researchers found a chain of weaknesses in the connected-car systems of two unnamed automakers that enabled remote access to customer accounts and vehicle controls, including door unlocking and engine start. Shubham Shah of Assetnote and independent researcher Sam Curry said the attack reached production ForgeRock identity servers used by both manufacturers’ mobile apps. The researchers tested the complete account-to-vehicle chain only against U.S. accounts and vehicles, although the affected identity systems served customers in multiple regions. Their technical write-up says both automakers fixed the issue roughly two hours after disclosure and rotated the exposed credentials.
The researchers did not name the automakers, and neither their write-up nor the available reporting assigns a CVE identifier or publishes a vendor advisory. The affected environments used ForgeRock Access Management and OpenIDM, now part of Ping Identity, to authenticate customers and manage account records. Shah and Curry said the systems ultimately exposed the same connected-vehicle functionality available to a legitimate owner, including vehicle location and telemetry, account and vehicle data, door lock and unlock, and remote engine start and stop. Depending on the model and subscription, the apps also supported horn, hazard-light and vehicle-location functions. The Register reported that researchers demonstrated additional commands including flashing lights and sounding the horn. [1]
In the more involved U.S. attack path, direct requests to administrative ForgeRock and Apache Felix endpoints were blocked by a web application firewall, but inconsistent URL parsing between the edge layer, Jetty and Felix allowed the researchers to reach the hidden Felix Web Console. The console still accepted its factory-default admin:admin credentials. From there, a ForgeRock OpenIDM scheduler could be configured to execute Groovy code, install an OSGi bundle and provide shell access inside the production identity process, according to the researchers’ account. That access exposed local OpenIDM administrative credentials and allowed customer records to be read or modified. Curry and Shah documented the path-confusion and default-credential failures, but did not identify a standalone ForgeRock software vulnerability or CVSS score.
The researchers used that administrative access to alter a target account’s email address and password, receive the normal email verification code at a controlled inbox, and complete the mobile application’s login flow. They then exchanged the resulting ForgeRock session for mobile-app OAuth tokens, retrieved the account’s vehicles and VINs, and issued commands through the same APIs used by the official apps. The researchers said they restored the test account and confirmed the physical results with the vehicle owner present; the write-up does not claim that an unknown attacker used the chain against victims in the wild.
For defenders, the incident highlights how a compromise of an identity-management tier can become a safety and privacy problem when mobile applications are trusted to relay high-impact vehicle commands. Automakers should remove default credentials from every deployed management interface, prevent administrative consoles from being reachable through public application infrastructure, normalize and validate URLs consistently across WAFs and back-end servers, rotate secrets after remediation, and review identity-provider logs for suspicious account changes, token issuance and vehicle-command activity. Owners should install available app and vehicle-service updates, enable account alerts where offered, and contact the automaker if unexpected login, password, email or remote-command notifications appear.
