07/01/2026
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.
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.
Front Gate Tickets and the device API
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.
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.
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:
WHERE deviceUID='<input>'Getting past the WAF
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.
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.
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:
deviceUID = x'+(SELECT CASE WHEN <COND> THEN 1 ELSE 0 END)-- -makes the WHERE clause resolve to deviceUID = N, where N is 0 or 1 depending on whether <COND> is true. Both 0 and 1 happen to match real rows in the DEVICE table, so the two cases return visibly different responses:
- true: response contains
MC70-023 - false: response contains
Intellitix Upload
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!
Reproduction
curl -s "<https://fgtapi.frontgatetickets.com/device?deviceUID=x%27%2B(SELECT%20CASE%20WHEN%201%3D1%20THEN%201%20ELSE%200%20END)--%20->" | grep -o 'MC70-023\|Intellitix Upload'
# → MC70-023 (true)
# swap 1=1 for 1=2:
# → Intellitix Upload (false)What was in the database
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:
- Staff credentials —
FGS_USER(EMAIL,PASSCODE,PASSCODE2,PERMS_JSON) - Customer information and credentials —
PERSON(EMAIL,PASSCODE,RESET_TOKEN) - Live tokens —
RESET_TOKEN,API_TOKEN,OAUTH_SERVER_TOKEN,oauth_access_tokens
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!
From a boolean oracle to festival administrator
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.
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 information, and I could issue unlimited “comp” tickets for any event I wanted.
I stopped here and did not view any records beyond what was needed to confirm the issue. The point was made: an unauthenticated request to a scanner API was enough to become an administrator of EDC, Bonnaroo, and every other festival on the platform.
Impact
An attacker with nothing but the public device endpoint could:
- Create complimentary tickets to any music festival using FGT
- Read customer information and credentials across every event on the platform
- Read and redeem live password reset tokens to take over staff and customer accounts
- Probably much more that I did not discover!
All of it from a single unauthenticated GET request, behind a WAF that provided a false sense of security rather than a real control.
Disclosure
I reported this issue to Front Gate Tickets and Live Nation. There is no public security contact for either, which is disappointing for a company of this size, but I was able to guess the correct email address to use. They quickly resolved the issue and informed me that a bug bounty program is coming soon.
Timeline
- 04/25/2026 07:02: Initial disclosure to Front Gate Tickets / Live Nation
- 04/25/2026 09:01: Vendor acknowledged the report
- 04/26/2026 14:23: Vendor confirms issue was resolved
- 07/01/2026: Public disclosure