In plain English
A search feature on a supplier portal let an outsider page through Tesla's internal staff directory, phone numbers and all.
The technical account follows below, for readers who want the detail.
Three lessons any team can use
Sensitive data needs to be limited at the source, not hidden in the interface.
Flexible search and query features deserve the same review as a login page.
Counts and metadata can leak as much as the records themselves.
The Challenge
A partner coordination portal for bodyshops and suppliers sat on a flexible query architecture that trustingly exposed internal data to external authenticated users. The profile lookup accepted OData style wildcards, so one crafted query iterated the entire employee directory with personal mobile numbers, directReports hierarchy, exact office addresses, and internal group memberships. The dataset console went further, returning developer emails plus full backend schemas with hidden fields and validation rules, while ticket search leaked global counts of 10,000 plus records in North America and 1,963 in Europe.
How We Proved It
Chained all three flaws into one consolidated report with proof for each endpoint, quantified the exposure in people, schemas, and ticket counts, and closed with concrete remediation guidance: sanitize metadata, scope every count to the viewer, and never trust wildcards on sensitive datasets. Triaged as P2 high impact with a $2,000 award, then published as a full technical writeup so other teams can audit their own query layers for the same pattern.
Tesla
Mar 31, 2026
Bug Bounty
Full Writeup
Researched and disclosed by Ridwan Adebayo. Read every step, payload, and takeaway.
Read on MediumRelated Case Studies
More disclosures from our researchers.
Know your risk. Strengthen what matters.
Tell us where you are, what you rely on, and what you need to protect. We will help you understand what to do next.