Introduction Finding a vulnerability in a massive infrastructure like Tesla's is always an adrenaline rush. While many researchers hunt for complex memory corruptions, sometimes the most impactful bugs hide in a "feature" — specifically, the way an API handles complex queries and internal metadata.

In this post, I'll walk through a series of vulnerabilities I discovered on `[REDACTED].tesla.com` that allowed for mass PII enumeration, database schema disclosure, and global business metric leaks.

The Target: [REDACTED].tesla.com The subdomain `[REDACTED].tesla.com` facilitates coordination between Tesla and its external partners (Bodyshops/Suppliers). Accessing it requires partner-specific provisioning.

Once inside, I realized the application used a highly flexible, query-based architecture that trustingly exposed internal data to external authenticated users.

— -

Finding 1: The `profilengroup` BOLA (PII Leak) The first major issue lived in the user profile look-up feature.

**Endpoint:** `GET /api/user/profilengroup?take=5&query=like(displayName,'cath%')`

The `query` parameter used a syntax similar to OData or a custom "Workforce Query Language" (WQL). By injecting wildcards like `like(displayName,'%')`, I was able to iterate through the entire internal employee directory.

The Impact: This wasn't just a list of names; the API "over-shared" sensitive fields including: - **Personal Mobile Numbers** of internal staff. - **Organizational Hierarchy** (the `directReports` field allowed mapping the entire reporting structure). - **Physical Office Locations** (exact building addresses). - **Internal AD/LDAP Groups** (revealing project team memberships and permission levels).

— -

Finding 2: The `manage/dataset` Schema & Admin Leak Beyond user profiles, I found that the application exposed its own architectural blueprint.

**Endpoint:** `GET /api/manage/dataset?query=space=='bodyshop-eu'&take=50`

By querying the dataset configuration, I was able to retrieve: 1. **Internal Developer Emails**: Fields like `createdBy` and `lastModifiedBy` leaked the `@tesla.com` emails of the internal admins and developers managing the platform — perfect targets for spear-phishing. 2. **Database Schema Documentation**: The response contained the full JSON schema for the backend tables, including hidden fields (e.g., `internalnotes`, `isdeleted`) and validation rules.

— -

Finding 3: The `search` Global Count BOLA (Business Intel) Finally, I investigated the search functionality for tickets. While I could only see the details of my own submissions, the API leaked the **Global Total Count**.

**Endpoint:** `GET /api/search?space=bodyshop-na&category=supplier&take=0&query=*`

By setting `take=0` and using a wildcard query, the server responded with the total number of records in the system.

Business Metrics Exposure: - **North America (NA)**: 10,000+ tickets. - **Europe (EU)**: 1,963 tickets.

— -

The Bounty & Conclusion Tesla's security team triaged the findings as a consolidated **P2 (High Impact)** issue due to the broad exposure of PII and internal operational data.

- **Severity**: P2 - **Bounty**: $2,000

Key Takeaways - **Sanitize Metadata**: Never expose `createdBy` emails or full `jsonSchema` data to external users. - **Enforce Strict Scoping on Counts**: Always filter "Total Count" responses to reflect only the records the user is authorized to see. - **Avoid Wildcard Trust**: If your API supports `LIKE` or `*` operators, ensure they are strictly limited to non-sensitive datasets.

Happy hunting!