admin / admin: Two Car Brands Unlocked Remotely

It's 2026. Do you know what the admin panel password was on the customer login servers of two car brands? admin. The username, too, was admin. Yes, that admin.

In research they published last week, security researchers Shubham Shah and Sam Curry found that panel, got in, ran code on the server, took over an account, and finally unlocked a car's doors and started its engine remotely. Then they stopped it and locked it again; the test car was their own, with the owner standing right next to it. I'm not sure whether to laugh or cry. Let me walk through what happened and what we should take away from it.

First, the "How Is This Real?" Part

Both brands handled customer sign-in through ForgeRock (now part of Ping Identity, sold as PingIDM). Its OpenIDM side, which holds customer records, ships with an Apache Felix admin console. That console's default username and password are admin / admin. And this has been documented for years. ForgeRock's own hardening guide even says to remove or protect the console before going live.

So there's no shiny new zero-day here. There isn't even a CVE. Someone just forgot to change a default password. Sounds familiar, doesn't it?

"But We Blocked That Panel From the Internet"

This is the most instructive part, because the brands had actually blocked the panel from the outside. So how did the researchers reach it?

The edge layer (CDN/WAF) and the Java app behind it parsed the same URL differently. By adding encoded slashes and extra characters, the researchers made the edge treat the request as a harmless static file, while the server behind it read the same request as the admin console path. The panel was technically closed, but because the two didn't speak the same language, the door cracked open.

Once inside the console, the rest was easy: they used its built-in scheduler to run small scripts and execute their own code on the server. That gave them a shell on the machine holding the customer records.

How Did They Get to the Car?

With code execution on the server, the rest was dominoes. The researchers changed a target account's email and password, signed in through the normal mobile app, and received the exact same access tokens the real app uses. The app treated them as the real account owner.

From there: unlock the door, start the engine, stop it, lock it. There's a nasty detail, too. Changing the email and password did not log the real owner out of the app, so the victim had no idea. The researchers could also redirect the account's alerts to their own phone.

For the record: the brands weren't named. The researchers ran vehicle commands only on cars they owned or were allowed to use, and say they tested the full chain only with US accounts and vehicles.

There's an Australia Version, Too

In a second case, admin credentials for the identity server on these brands' Australian side were left right in the app's code; put there for a test setup and never removed. Combined with the first method, the researchers say they could send unlock and engine-start commands to these brands' cars in Australia, the US, and Canada.

"Temporary" credentials baked into the code. We know that one from somewhere, too.

Good News: It Was Fixed Fast

About two hours after the researchers reported it, the systems were fixed. So the brands took it seriously and moved fast; credit where it's due. The researchers also restored the email they had changed for testing.

Who Is Affected / What Should You Do?

Not car owners directly; the real message is for us, the developers and the people standing systems up. This wasn't an exotic attack, but three very familiar mistakes stacked on top of each other. Check these three in your own projects today:

• Default credentials: Any tool you install (admin panels, databases, identity servers, message queues) may still have its default user/password. For the Apache Felix console specifically, check the /system/console path: remove it or change its password.
• The "behind a WAF, so we're safe" fallacy: Don't hide admin pages with edge/WAF path rules alone. The edge and the app behind it can parse a URL differently; that's exactly what opened the door here. Hiding isn't protection; put that endpoint truly behind authentication.
• Secrets baked into code: The usernames, passwords, and tokens you "just put in for testing" stay in the repo. Set up secret scanning, and keep test-environment credentials out of production code.

The full technical details are in Sam Curry's write-up and Shubham Shah's blog; the ForgeRock/Ping side has its official hardening guide. But the real issue isn't technical. In 2026, our biggest vulnerability is still saying "I'll change that default password later" on the way to production.