Backstage access: an unauthenticated SQL injection in Front Gate Tickets
Backstage access: an unauthenticated SQL injection in Front Gate Tickets
07/01/2026<br>If you have been to a major music festival in the United States, there is a good chance your ticket was sold through Front Gate Tickets (FGT), a Live Nation/Ticketmaster subsidiary that handles ticketing and payments for events like EDC, Bonnaroo, Outside Lands, and more. I noticed that nearly every festival I could find funneled back to the same handful of FGT domains, and that the systems behind them looked quite old.<br>Within a short while I found an unauthenticated, trivially accessible SQL injection in the core device API that let anyone read the entire fgs database, containing over 500 tables of customer information, ticketing records, staff credentials, and more. By reading the password reset table and redeeming a token, I was able to log in as a Front Gate Tickets administrator with write access to every single festival on the platform.<br>Front Gate Tickets and the device API<br>Front Gate Tickets appears to run both the online ticketing and the offline physical box office infrastructure for its events. This means there is online infrastructure meant for both consumers and on-site staff (ticket scanners, box office employees, etc). I wasn’t able to find any obvious issues in the consumer apps or in the admin tools directly. Instead, while running ffuf on the fgtapi.frontgatetickets.com API, I got lucky and noticed that any path that contained the word device was receiving a unique error message that a deviceUID parameter was missing.<br>It seems like there is some kind of middleware intercepting any request involving the device keyword and returning the ID and name of the device corresponding to the provided deviceUID without any authentication. At first, the IDs I provided were not valid and so it was creating a new device in the database every time I made a request and returning a new device ID/name.<br>Without much hope in my head, I figured I should check for SQL injection anyway. A deviceUID of 12345 returned successfully, but a deviceUID of 12345' caused the request to hang and never complete. The parameter appears to have been concatenated straight into the query:<br>CopyWHERE deviceUID=''<br>Getting past the WAF<br>The API uses AWS WAF, and despite my best attempts with sqlmap, it never got a foothold. I almost thought there was no SQL injection at all and almost gave up. The WAF blocks the obvious building blocks of an injection.<br>However, I gave this endpoint to Claude Code running Opus as a last resort, and it quickly discovered that the WAF only inspects the outer level of the input. Nesting the same constructs inside a derived subquery passes without issue.<br>However, the SQL injection was pretty constrained and I could not read the response of a query directly. Instead, to read data out one bit at a time, I needed a boolean oracle to use the device name in the output as a way to read the result. MySQL gave Claude a simple one: a string like 'x' added to a number coerces to numeric 0. So a payload of:<br>CopydeviceUID = x'+(SELECT CASE WHEN THEN 1 ELSE 0 END)-- -<br>makes the WHERE clause resolve to deviceUID = N, where N is 0 or 1 depending on whether is true. Both 0 and 1 happen to match real rows in the DEVICE table, so the two cases return visibly different responses:<br>true: response contains MC70-023<br>false: response contains Intellitix Upload<br>Opus wrote this entire exploit chain itself and I had to do very little work aside from get it started. This was quite refreshing compared to manually playing SQL injection CTFs 10 years ago!<br>Reproduction<br>Copycurl -s "" | grep -o 'MC70-023\|Intellitix Upload'<br># → MC70-023 (true)
# swap 1=1 for 1=2:<br># → Intellitix Upload (false)<br>What was in the database<br>The fgs database has over 500 tables. I read only 1–5 records from a handful of them to verify impact. A few tables stood out:<br>Staff credentials — FGS_USER (EMAIL, PASSCODE, PASSCODE2, PERMS_JSON)<br>Customer information and credentials — PERSON (EMAIL, PASSCODE, RESET_TOKEN)<br>Live tokens — RESET_TOKEN, API_TOKEN, OAUTH_SERVER_TOKEN, oauth_access_tokens<br>The injection is read-only, but "read-only" is not reassuring when one of the things you can read is the live password reset token table!<br>From a boolean oracle to festival administrator<br>The RESET_TOKEN column holds valid, redeemable password reset tokens. Requesting a password reset and then reading a token through the injection let me take over an account without knowing its password. From there, the platform gave me full access to every festival using FGT.<br>At some point, it seems like they stopped renaming events for their subsequent years, as the 2025 events had new dates and tickets for 2026.<br>Each one opens into the full box-office interface: events, inventory, pricing, and checkout. The same account could search the customer database directly for each event. A search for "chris" returned thousands of records and order...