This is quite a different post as it is not related as usual to Windows vulnerabilities 😉.

In the past period, I have been looking into the myAudi connected vehicle platform “Audi Connect and Remote Control”, specifically the APIs behind the myAudi web and mobile apps. The reason is quite simple. I was frustrated by my own app suddenly stopping working intermittently, going dark for 2-3 days and then starting to work again as if nothing had happened.

I opened a couple of tickets with Audi Digital, but they ultimately led nowhere 😦

So I decided to understand how it was working under the hood. In fact there are some resources online that interface with this digital platform, from the login process up to accessing some calls about vehicle information. These community projects gave me a starting point to understand the authentication flow and the general API structure before diving deeper into my own analysis.

Being a hobby security researcher, rather than just waiting for an improbable fix I decided to look under the hood properly. I set up Burp Suite, analysed the web portal and the Android APK, and started to look at the API calls…

My goal was to understand what happens when you refresh the status of your vehicle from the mobile app, given that in case of error I got back some weird error code E:CV.PA.5 (…).

Intercepting these calls means that you have to set up a smartphone emulator and do some work to intercept the traffic with Burp. I was not that enthusiastic given that I’m lazy, but this was the only opportunity so I decided to install Android Studio, set up a virtual Pixel 7 Android device, download the myAudi app, push it on the device, configure the proxy and start the app.

But nothing happened – no traffic in Burp. Obviously the app used certificate pinning! So I had to add some additional components: Frida server and Objection to hook into the app and bypass certificate pinning validation at runtime.

After several attempts I was finally able to get the beast working:

The “wakeup” endpoint resulted in being hosted by emea.bff.cariad.digital:

Once the request with the Vehicle Identification Number (VIN) was created, the ID of the request was returned. The next step was to check the pending requests endpoint and verify the status for each request ID, essentially a polling mechanism to determine whether the vehicle had successfully received and processed the command.

The callback URL is the endpoint that the vehicle connects back to once it has successfully processed the wakeup command.

With all this information in hand, I created a PowerShell script that runs on a schedule once per day. It authenticates against the VW/Audi identity endpoints, retrieves the JWT tokens, and executes the wakeup request to keep the vehicle connection alive.
So I noticed that the wake-up request stops working for 2-3 days and then starts working again. I still don’t know what or who it depends on. The car? The portal? Who knows🤷‍♂️​

With this whole set of APIs now mapped out, my curiosity naturally turned to the security of these implementations, specifically whether there could be any unexpected information disclosures or potential for abuse.

The first thing that seemed at least somewhat strange to me was that, once you create an account on the myAudi portal (and other related VW Group brand portals), you can add any vehicle simply by knowing its VIN. After doing so, you become a “GUEST_USER”, which in theory should provide only very limited access to the vehicle’s configuration and features.

A VIN is not a secret , it appears on insurance documents, registration papers, service records and is visible through the windscreen of every car on the road. The vehicle association model needs to treat it accordingly

This piqued my curiosity, so I started digging deeper. Luckily, up to now I could not find so many things that could be abused without becoming a primary or secondary user, a process that requires some additional security steps to perform, but nevertheless I found some issues worth reporting.

Testing was limited to my own accounts and voluntarily associated vehicles for the purpose of responsible security research.

1.GraphQL Introspection Enabled in Production

When logging in into the web portal or via app, you get a list of associated cars via GraphQL query:

The first thing I tried, as a “Guest User” after associating my own car, was to check if the “Introspection Query” was enabled.

If so, it gives the full API schema, exposing all available queries, mutations, arguments, and internal data types:

Even if I was not able to find undocumented “privileged” mutations, GraphQL introspection is commonly disabled in production environments to reduce unnecessary exposure of API structure and internal object model

During my tests, I found other GraphQL endpoints that had the Introspection disabled.

2.Vehicle Data Disclosure

There is information that a guest user can access, including license details and expiration dates, service status, and similar metadata.

For example, once a vehicle was added, the vehicle management endpoint at msg.audi.de returned the full hardware identifiers of the embedded SIM, including the IMEI and ICCID (when available):

The IMEI and ICCID are the unique identifiers of the embedded SIM card and device inside your car. Think of them like the serial number of your car’s phone. These identifiers are permanent and exposing them to anyone who knows your VIN means that a malicious actor could potentially use them to track your vehicle’s cellular connection or target the embedded SIM. Not something you want strangers to have access to.

3.Poll and Retrieve Pending Eequests

To my surpirse I disovered that as a guest user it was possible to access the pending requests initiated by the primary user with a specific VIN. Below, a wakeup request is intercepted:

In the case of a “honk & flash” request, a feature that allows you to locate the car by activating the indicators and the horn, the response to the request also includes the GPS location of the user who performed it.

Again, this is not the kind of information you would want to expose to strangers, right?

Additionally, knowing whether the vehicle has been unlocked could obviously be abused by malicious actors:

Other interesting endpoints

The entire VW Group API ecosystem is quite complex. Identity is managed by the identity.vwgroup.io endpoints, where upon authentication you receive several JWT tokens scoped to specific features and also tailored to the brand of your vehicle.

On top of that there is cariad.digital using the BearerToken.access_token:

which handles all the digital services for the onboard MMI system.

The legacy vwg-connect.com infrastructure manages roles, rights and vehicle operations at a lower level.

Understanding how these layers interact with each other was key to mapping a potential attack surface. I’m still working on it 😉

Disclosure

I informed the Audi and CARIAD security teams about the findings. The third one, related to intercepting pending requests as a guest user, has been fixed. The CARIAD team asked me to verify the fix and I can confirm that it is no longer possible for a guest user to see the pending requests of another vehicle owner.

The other findings I believe are still under evaluation. I shared my thoughts with them directly: as an Audi owner, I am genuinely concerned that anyone who knows a VIN (which is visible through every car’s windscreen) can add that vehicle to their myAudi account and access information about it and potentially about its owner.

Even if some functionality gets restricted going forward, I would strongly recommend that VW Group and CARIAD review the entire vehicle association logic from the ground up rather than patching individual endpoints.
I followed up several times, including asking about some form of recognition for the time and effort invested in this research.

Unfortunately, the replies stopped coming. This is not exactly what you would expect from companies of this size and reputation when a researcher takes the responsible disclosure process seriously and acts in good faith.
I hope this post is useful to the security community and puts some pressure on the right people to finish the job properly.

Conclusions

While this is not exactly what I normally do in my research, I have to say it was a fun and rewarding experience. I think curiosity is the main driver in security research, regardless of the technology behind it. Whether it is Windows internals, Active Directory, Entra/Azure, Web APIs etc… the approach is always the same, think outside the box and experiment.

That’s all 😉