Cross-Tenant BOLA and Unauthorized State Tampering in a Forgotten Fleet Platform

Context & Scope#

During an independent security assessment of a commercial fleet telematics and carrier logistics provider, I investigated auxiliary and pre-production web assets deployed across the organization's cloud container infrastructure. Many transport enterprises deploy specialized sub-services or secondary dashboards to pilot upcoming partner integrations—such as dedicated fleet management tools for third-party carriers, sub-contractors, and vehicle leasing partners.

While mapping external application assets, I identified an abandoned pre-production fleet management portal hosted on a forgotten cloud deployment (staging-fleet.target-platform.local). The application had been left reachable on the public internet and connected to active or mirrored operational data. The assessment aimed to determine whether tenant isolation and administrative boundaries were enforced, or whether an untrusted session could access cross-tenant fleet records.

Tools & Setup#

• Burp Suite - intercepting HTTP/HTTPS traffic, replaying state-modification actions via Repeater, and evaluating multi-tenant parameter isolation.
• Claude Opus - analyzing client-side JavaScript assets to map hidden fleet management API paths and correlate tenant data schemas.
• Browser DevTools - analyzing network traffic, capturing API authorization headers, and reviewing compiled client-side bundles.
• Postman & cURL - crafting parameterized HTTP requests, manipulating object identifiers, and verifying server-side access control responses.

Technical Walkthrough#

1. Public Registration on an Abandoned Environment: Visiting the landing page confirmed that unauthenticated visitors could not view internal dashboards. However, the registration endpoint was completely exposed to the public. The onboarding flow accepted arbitrary email addresses and contact information without requiring email verification, domain restrictions, or manual administrator approval.

   Upon completing the self-service form, the backend issued a standard JSON Web Token (Bearer token) granting immediate authenticated access:

   http

   POST /api/v1/fleet-operations/auth/register HTTP/1.1
   Host: staging-fleet.target-platform.local
   Content-Type: application/json
   
   {
     "email": "test-analyst@example.local",
     "fullName": "Security Audit Test",
     "phone": "+48000000000"
   }

2. Frontend Routing Reconnaissance: Inspecting the application's compiled client-side bundles revealed that the user interface was designed for multi-tenant fleet operations. The client bundle contained definitions for all internal API endpoints governing fleet rosters, driver assignments, vehicle compliance documentation, and disciplinary blacklists.

   Although the user interface filtered views according to the authenticated profile's assigned fleet, the underlying REST API relied entirely on client-supplied parameters without validating tenant ownership.

3. Cross-Tenant Object Reference & Mass Driver Disclosure (BOLA): Using the newly acquired session token in Postman, I queried the fleet registry endpoint:

   http

   GET /api/v1/fleet-operations/fleets HTTP/1.1
   Host: staging-fleet.target-platform.local
   Authorization: Bearer <unverified_user_token>
   Accept: application/json

   The endpoint responded with HTTP 200 OK and returned a complete listing of all fleet organizations registered across the platform, including their unique identifiers (fleetId) and owner details.

   Taking a target fleetId belonging to an external, competing fleet partner, I queried the driver assignment endpoint:

   http

   GET /api/v1/fleet-operations/drivers/fleet/66197440-2ab0-4f20-bfbe-2363408aa516 HTTP/1.1
   Host: staging-fleet.target-platform.local
   Authorization: Bearer <unverified_user_token>
   Accept: application/json

   The backend returned HTTP 200 OK containing the full driver roster for that fleet (66 active driver records in a single query). The payload exposed sensitive driver contact information, residential details, active vehicle assignments, and personal phone numbers, presenting a direct vector for targeted social engineering and courier impersonation.

4. Confidential Vehicle Documentation Access (IDOR): The vulnerability extended into compliance and asset management modules. Supplying arbitrary vehicle identifiers to the document endpoint exposed confidential commercial vehicle records:

   http

   GET /api/v1/fleet-operations/vehicles/documents/98ef42cf-6d9e-44ac-9384-8cd65e6fc4c0 HTTP/1.1
   Host: staging-fleet.target-platform.local
   Authorization: Bearer <unverified_user_token>
   Accept: application/json

   The response leaked cleartext URLs and metadata for private vehicle inspection logs, leasing agreements, and municipal commercial insurance policies without verifying whether the requester owned or managed the vehicle.

5. Unauthorized Blacklist Tampering: Beyond passive data leakage, the API exposed sensitive state-modification capabilities without functional authorization guards. The portal included a disciplinary blacklist module intended to prevent suspended couriers and drivers from accepting routes.

   Submitting a DELETE request against the blacklist resource with a target record identifier bypassed all administrative role checks:

   http

   DELETE /api/v1/fleet-operations/blacklist/e2b4f981-54c3-41d7-b829-10769a239b12 HTTP/1.1
   Host: staging-fleet.target-platform.local
   Authorization: Bearer <unverified_user_token>

   The server returned HTTP 200 OK and permanently removed the driver from the global blacklist, allowing unauthorized reversal of disciplinary bans across the entire fleet network.

Findings & Severity#

Responsible Disclosure & Takeaways#

Because this abandoned portal exposed active contractor records and allowed tampering with disciplinary status, I reported the findings directly to the organization's technical leadership. The report detailed the exposed endpoints, reproducible cURL commands with sanitized identifiers, and remediation recommendations.

The vendor verified the report, acknowledged the severity of the findings, and immediately disabled public registration on the domain before taking the entire abandoned container offline.

From an application security perspective, this assessment highlights two important takeaways:

1. Asset Lifecycle Governance & Pre-Production Hygiene: Pre-production, staging, or abandoned project branches must never be exposed directly to the public internet without network-level access controls (such as VPNs, IP allowlisting, or edge identity-aware proxies). Furthermore, pre-production instances must not share or synchronize production databases containing real customer or driver PII.
2. Context-Aware Object Authorization: Verifying that a request carries a valid session token is only the first step of authorization. Every controller handling multi-tenant resources must validate tenant context—ensuring that the requested object belongs explicitly to the authenticated user's organization before returning data or committing state changes.