> November 10, 2025: No response, followed up.
> November 17, 2025: No response, followed up and copied some additional people on the thread.
> November 20, 2025: It was no longer possible to access any of the internal APIs. The primary vulnerability was now fixed.
> July 27, 2026: Published
Quite the generous timeline on this person's behalf.
Sometimes overlapping, but they are not the same thing.
Wouldn’t it be better if your phone/devices would pair directly with the car, exchange keys, and have the company cloud only function as a proxy.
On holiday a guests BMW didn’t want to “start” anymore because it couldn’t phone home because of lack of phone reception. They had to contact the dealer at home and move heaven and earth to get some dealer code to allow the car to start again for a while. Why is this even allowed?
It's a shame. I will continue to purchase vehicles with as internet connected and touch screen features as possible. My 2025 Toyota has knobs and a physical key still. Terrified what will be left on the market when I have to get a new vehicle in (hopefully over) 15 years.
Surely there's more to this story? AFAIK last time I heard about something like this, it was because the guy's car was parked 5 stories underground, and didn't carry his car keys, because he was using his phone to unlock all the time.
I hope you aren't suggesting that set of details makes this okay. I should be able to park in a faraday cage 2 miles underground and still start it the same as I can on the surface. Including with my phone, if it's equipped with phone-as-key.
The phone-as-key shouldn't only work when online and shouldn't require the car to be online, either. And this is a problem trivially solved with proper use of cryptography.
The reason for this is that if the car gives people the ability to start a trip with a phone, it's dangerous to assume they'll always carry a keyfob as a backup. Just like I don't carry two car keys.

Eaton • Jul 27, 2026
Welcome to my next blockbuster automotive hack! This one has been in the works for a long time with roots going back to early 2024 when I disclosed the Toyota insurance company hack. Fun fact: I was actually trying to find a vulnerability in My Eicher at that time, but was unsuccessful. It wasn’t until more than a year later in 2025 that I stumbled upon a breakthrough that cracked My Eicher wide open.
Unless you are in India, you probably haven’t heard of My Eicher before. It is an app/website that lets commercial vehicle customers track and manage their fleets of trucks and buses. You can do fun things like real-time-track vehicles, view the live gauge clusters, set geofences, and so much more. The website is here, and there is an Android and iPhone app.
The vulnerabilities being disclosed here only impact commercial vehicles and customers in India.
The vulnerability was incredibly simple and discovered through sheer luck. Here is an API that is used on the homepage of the website to check your mobile #: https://www.myeicher.in/cepauthmgr/user/validateMobileNo
The Javascript on the website has many other APIs like that. There were some other interesting ones, but nothing that could be used to hack the entire platform. Then, just randomly one day, I decided to try going to this endpoint on my browser: https://www.myeicher.in/cepauthmgr/user/
In 99% of cases, walking up the API path results in an HTTP error. This time, it revealed a big list of all the user-related APIs:
You can view the full list here.
Even better, they were unauthenticated! I found a “customers” endpoint and it revealed a massive list of 748k customers:
There were also “users” and “persons”:
It even returned the password to you. It was encrypted though, so it couldn’t be used. This was still a massive breakthrough – it was no longer difficult to find people who use this system. These APIs gave me the entire list of accounts. If there was some sort of login exploit, it would be game over for everyone in here.
My luck continued to grow: there was an API that returned the entire list of 2.5 million OTPs going back to 2021:
There were also more specific APIs to return OTPs for specific mobile #s:
You can probably guess where this is going. The stage has been set for an account takeover!
Step 1: Pick a mobile # from the user list and send the OTP. I picked one linked to a large engineering company.
Step 2: Use the API to find the OTP by mobile #:
Step 3: Plug it in. This technique gave me full control over any user account, and by extension, the vehicles/fleets.
The side effect of all this is that you tip off the person by actually sending them the OTP, so it’s unfortunately not a silent account takeover. However, there was a second account takeover method! There are APIs to update the password on the account, so you could set one and then log in using password. The user presumably would not be notified, but I am not 100% sure.
Here’s some additional screenshots documenting what kind of things I had access to.
This is the response from the vehicles API. There were 676k!
This is a map that lets you track all your vehicles:
Here are the individual tracking details of specific vehicles:
The live vehicle cluster, which supposedly is representative of what the driver sees:
Here are many other features:
It gets worse! There were a few APIs relating to documents that revealed 76k documents and images people have uploaded. This includes very sensitive ID documents like Aadhaar cards and driving licenses.
I found someone who had reported a vulnerability to VECV in the past and they gave me their infosec email address.
After November 2025, I had some additional concerns that I attempted to relay to them, including over the general customer support line, but was unsuccessful in getting in contact with anyone there who cared enough to investigate them. After a few months of waiting, I gave up on these other concerns. At least they fixed the primary vulnerability.
Get an email notification every time something new is published.