Broken Access Control on Fleet Admin Endpoints Exposes Every Active Rental Globally

The Vulnerability

An electric scooter rental app's backend exposed three fleet management endpoints that were intended for internal operators (battery swap teams, repair crews, regional managers). The endpoints checked that the request had a valid login token but did not check whether that token belonged to an account with fleet management permissions.

A standard rider's token, captured from normal app traffic, contained only the consumer role:

{`{
  "userId": "",
  "role": {
    "global": ["rider"],
    "zone": null
  }
}`}

Despite this, the same token returned HTTP 200 with full data from the fleet endpoints. Other admin paths on the same backend correctly rejected this token with "Missing required scopes", proving the role-check middleware existed but was not applied to the fleet endpoints.

The Attack

The token was captured by running the official Android app on a rooted device with a TLS interception proxy. The signing pin was bypassed with a standard hooking framework. Once the token was recovered, the rest of the attack was a single curl command per endpoint.

Active rentals across every market

One request to the active rentals endpoint returned 781 active rides at the time of testing, covering every operating country. Each entry contained the rider's persistent user identifier, the vehicle code, the zone or city, the start time, and the duration so far.

Zone configurations

A second request returned 226 zone configurations: geographic boundaries, local pricing, currency, VAT settings, sleep schedules, and operating company entities for every market.

Fleet management tasks

A third request returned 200 active operational tasks: battery swap jobs, repair tickets, and rebalance assignments, including vehicle identifiers and current battery levels.

Authentication versus authorization

A request without any token returned HTTP 401, confirming authentication was checked. A request with the rider token returned HTTP 200, confirming the missing control was authorization. A request to a separate admin endpoint with the same rider token returned 401 with "Missing required scopes", proving the same backend already had role-based access control implemented elsewhere and simply did not apply it to the fleet endpoints.

The Impact

Real-time tracking of any user

The user identifier returned for each active ride is a persistent UUID that stays the same across rides. An attacker polling the endpoint every few seconds builds a continuous timeline of when a target rides, in which city, on which vehicle, and for how long.

Pattern-of-life analysis

Over days of polling an attacker reconstructs commute patterns, frequently visited zones, and daily schedules for any rider on the platform. For a single user this is a privacy violation. For journalists, activists, or domestic abuse victims it is a safety risk.

Scale

781 active rides were returned at 05:28 UTC, early morning in Europe. Peak hours would expose significantly more. All operating markets were included.

Operational data

The zone and task endpoints leaked internal pricing, operating margins by city, geographic boundaries, and live maintenance operations. A competitor or a bad actor could use this to undercut local pricing or to predict where unmaintained vehicles will be available.

Low barrier

Any free rider account was sufficient. The only prerequisite was capturing one HTTP header from app traffic, which is trivial on a rooted Android device.

Remediation

• Apply the existing role-check middleware to all fleet management endpoints. The same backend already returned the correct "Missing required scopes" error on other admin paths and simply did not apply that gate here
• Reject any request to fleet endpoints whose token does not include a fleet management role
• Audit the access logs to identify any consumer tokens that have already hit these endpoints and rotate or revoke as appropriate
• Add monitoring on these endpoints to alert on unexpected request volume from accounts that do not hold a fleet role
• Treat the persistent user UUID as sensitive and avoid returning it on any consumer-facing response unless strictly necessary