Vantrue's API Never Asked If userId Was Really Yours

I bought a Vantrue dashcam a while back and set up the app like everyone else. Nothing fancy. Later I got curious about how the cloud side actually worked. I decompiled the Vantrue app APK, pulled out the API paths and headers, registered a couple of test accounts on my own, and hit the endpoints manually with curl. I only ever looked at data tied to those accounts I created. No fishing through strangers' stuff.

What I found freaked me out. I disclosed it to Vantrue on May 7, 2026. They replied that the backend was fixed and deployed. I held the post back until I could retest. As of late May 2026, the same bugs still reproduce on production. This writeup is public because users deserve to know the cloud API is still not enforcing access control.

How I even started looking

I did not MITM the app or run a proxy. I decompiled the APK and read how the client talks to the backend: hostnames, path prefixes, the token header, which query params go on each call.

Vantrue's backend is not hidden behind some mystery wall. You hit a bootstrap URL on prod.vantruecam.com with your country code and it hands you a big JSON list of every live API endpoint. Over a hundred of them. No login required for that part.

From there it is normal HTTP to us1 / us3 and friends. You log in, you get a token in a header, you call endpoints.

I had two test accounts so I could see what happened when account A asked for account B's data. Spoiler: the server did not care.

What I actually sent

I ran the requests below by hand after pulling the routes from the decompiled app. Login is form-urlencoded, not JSON.

1. Bootstrap (no auth)

curl -s "http://prod.vantruecam.com/server/fourG/interfaceAddress/getAppInterfaceAddressList?countryAbbr=US"

2. Login

curl -s -X POST "https://us3.vantruecam.com/server/fourG/appAccount/appAccountLogin" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "accountType=2" \
  --data-urlencode "email=<my test account>" \
  --data-urlencode "passWord=<my test password>" \
  --data-urlencode "countryCode=1"

3. Device list

curl -s "https://us3.vantruecam.com/server/fourG/deviceInfo/getDeviceInfoListByUserId?userId=ACCOUNT_A_USER_ID" \
  -H "token: ACCOUNT_B_TOKEN"

4. Cloud video list

curl -s "https://us3.vantruecam.com/server/fourG/deviceVideo/findDeviceVideoList?userId=ACCOUNT_A_USER_ID&imei=ACCOUNT_A_IMEI&videoType=2&pageNum=1&pageSize=20" \
  -H "token: ACCOUNT_B_TOKEN"

5. File server (no token)

curl -sI "http://app.vantruecam.com/file/us/IMEI/DATE/Parking/FILENAME.MP4"

The main bug: userId in the URL is the whole security model

Almost every "get my stuff" endpoint takes userId as a plain query parameter. The API checks that your token is present and not expired. It does not check that the token belongs to the userId you asked for.

So on my second test account I changed userIdto my first test account's number and suddenly I was looking at the other account's device list, video metadata, cloud storage info, the works. HTTP 200 every time.

Every cloud video and event clip I saw in the API came back with longitude and latitude in the JSON, not just a timestamp. You could pin where the car was when each file was recorded.

WiFi passwords riding along in the device list

The device list JSON included the dashcam WiFi hotspot name and password in plaintext. SSIDs follow a pattern like N5S_VANTRUE_ plus part of the MAC.

Files on app.vantruecam.com are just... public URLs

The API returns fileDownloadPath values with no token, expiry, or signature. HEAD with no auth still returns 200 and video/mp4 on current clips.

What an attacker can do

1. Register any free account.
2. Grab endpoint list from prod (no auth).
3. Log in, get token.
4. Walk userId values and pull device lists.
5. List cloud videos with victim IMEI.
6. Download MP4s from app.vantruecam.com with zero extra credentials.

Disclosure timeline

2026-05-07 — Disclosed to Vantrue.

I took that at face value and retested before publishing.

Retest after the vendor fix claim (2026-05-28)

I logged in again with my test account and ran the same checks against us3.vantruecam.com.

• F-01 IDOR: still broken. With my token, other users' userId values still returned HTTP 200 and their device rows.
• F-02 WiFi leak: still broken. Cross-user device responses still included wifiPassword in plaintext.
• F-03 file server: still broken on fresh URLs. Video list returned paths dated 2026-05-26. HEAD with no auth: HTTP 200, video/mp4, ~27 MB. Old May paths from my report now 404.
• Partial change only: some WiFi-only devices now return an empty imei, which blocks video listing unless you already know the IMEI. That is not authorization.

Why I am posting this now

Vantrue's ticket says the backend fix is deployed. My retest says otherwise on the live US API. If you use Vantrue cloud features, assume your footage metadata and WiFi credentials were exposable and may still be today.

Changing your dashcam WiFi password does not fix this. The app syncs it to the cloud and the device list API still returns whatever you set. Until Vantrue removes that field and enforces access control, a new password is just a new line in someone else's JSON.

Push Vantrue support for a real patch: enforce userId server-side, drop wifiPassword from responses, and require auth on file URLs.