Unauthenticated Staging Assistant Leaks 3M Production Ticket Barcodes
The Risk
An internal staging copy of the company's analytics assistant was wide open on the internet and was reading the real production ticket database. Anyone could ask it for the entry barcodes of any future event at any partner venue and download the result with no login. The researcher pulled 3.3 million ticket records from eight partners, including roughly 22,000 live tickets whose barcodes could be cloned and scanned at the door, blocking the real customers who had paid for them.
The Vulnerability
The internal staging assistant API hosted at services.staging.<company>/agents/<assistant>/partner/{partner_id}/... exposed 14 functional routes (chat, dataset preview, dataset download, charts) that accepted unauthenticated requests for any production partner id and returned live production data. The same paths on the production host correctly rejected unauthenticated requests with 401. The staging host had no auth check and no partner-to-caller binding, yet it had read access to the same warehouse driving the live consumer site and the partner ticket scanners.
Three evidence points confirmed the data was real production data, not staging seed:
- An exfiltrated row matched a live event listing on the public consumer site character for character on the same day.
- Row counts decremented in real time across a two-hour window as tickets were sold, redeemed, or cancelled in the warehouse.
- Future event dates were concrete and matched real upcoming venue schedules.
The Attack
- Open the staging assistant chat endpoint for any production partner id. POST a message asking for the ticket-sales row count. Receive a
run_id. - Poll the run until status is
completed. The assistant returns the real row count for that partner. - POST a follow-up message asking the assistant to create a dataset artifact filtered to currently-exploitable rows (non-null barcode, not yet validated, not cancelled, event date in the future). Capture the dataset id.
- GET the dataset preview to confirm columns and row data: order id, order item id, barcode, plan name, venue name, city, event start date.
- GET the dataset download endpoint. Receive a signed cloud storage URL. The signed URL is readable from any IP with no further authentication.
What the exported data contained
The columns confirmed accessible included order id, order item id, barcode, plan id, plan name, session, venue, city, country, event start and end dates, status, validation and redemption timestamps, buyer and owner user ids, and demographic gender attributes. The barcode field matched the format and field name consumed by the partner scanner application's validate-code endpoint.
The Impact
Reproduced unauthenticated across multiple production partners totalling more than 3.3 million ticket records. On one partner alone, hundreds of thousands of total records contained several thousand currently-clonable tickets (event in future, not yet validated, not cancelled). Applied across the artifact-confirmed partners, that projects to roughly 22,000 clonable tickets, or a six-figure sum in cloneable inventory at a conservative average ticket price.
Downstream consequences:
- Ticket cloning. An attacker generates barcode images from exfiltrated values. The legitimate customer arrives at the venue, finds their ticket already redeemed, and is turned away.
- Customer harm. Real customers who paid for tickets get denied entry at the gate.
- Direct revenue loss and reputational damage. Each cloned ticket equals one paid customer denied plus one fraudulent entry. Visible chaos at scanner gates damages partner relationships.
- Personal data exposure. Buyer and owner user ids linked to demographic attributes were exported. Non-null email and name counts matched the row totals for the analyzed partner.
- Order id exposure. Sequential 8-9 digit order identifiers can seed downstream account-takeover, refund-abuse, or order-search probing.
Remediation
- Enforce authentication on every route under the assistant API on the staging host. Match the production access-control behavior.
- Bind every assistant run, thread, dataset preview, dataset download, and chart call to an authenticated identity that has been authorized for the requested partner id.
- Remove the staging assistant's read access to the production data warehouse. If staging must reach production data, gate it behind internal-only network or service-account authentication.
- Disable unauthenticated signed download URL minting. Tie URL minting to authenticated callers and short TTLs.
- Audit existing assistant-generated artifacts and cloud-storage access logs for unauthorized reads.