Red Agent rips open airline GraphQL bookings
An autonomous red-team agent hit an airline GraphQL API from a public root URL, minted an anonymous session, ran schema introspection, and found 514 queries and 428 mutations exposed. Sequential booking IDs unlocked full records and destructive mutations. Frontend auth did nothing; resolver-level authorisation was missing. Classic BOLA, industrial scale.
Airline booking backend, GraphQL. An autonomous Red Agent walked in from a public root URL with no credentials and, within fifteen minutes, had read and write access across live passenger records. If you still trust frontend login screens to protect server data, this is your reminder that resolvers decide reality.
What broke was plain: Broken Object-Level Authorisation (BOLA). Backend resolvers accepted sequential integer booking identifiers and never checked whether the anonymous session could touch that object. The agent first replayed a client token flow to mint an anonymous session via API kdf endpoints, then ran GraphQL introspection. The anonymous role saw a sprawling schema: 514 queries and 428 mutations.
The path in plain sight
From there the agent cherry-picked mutations that took simple integers. It fired twenty sequential booking IDs and got twenty distinct, complete records back. We are not talking scraps. The responses included names, dates of birth, emails, phones, billing addresses, masked cards with expiries, loyalty numbers and full itineraries. To cross-check, the agent hit related REST endpoints for passengers, contacts and payments. Same story.
Worse, the anonymous session was allowed to mutate. Change contact emails, delete flight segments, cancel trips, split passenger groups, override pricing, issue refunds. You can sketch the attack chain: swap the contact email on a live booking, trigger a cancellation or refund workflow, and you have both disruption and money movement with no account compromise.
Why scanners missed it
None of this trips classic Dynamic Application Security Testing. The requests are valid GraphQL, not exploit strings. There is no stable signature, just business logic that assumes the client will be nice. The agent got in by studying client-side JavaScript, reproducing the token dance, mapping schema relationships and probing integers. That is manual analyst work, now on rails.
The write-up is a red-team blog, not a lab report. Target details are redacted, and we do not get exhaustive telemetry. What is missing in the gaps: whether rate limits or anomaly detection fired, whether introspection exposure was deliberate, and how sparse the ID space really was. None of that rescues the core finding: resolver-level checks were absent where they mattered.
The exploitable idea worth testing in any GraphQL engagement is obvious: follow the client to an anonymous token, introspect, find integer-keyed mutations, then walk the ID space and validate via independent resources. If an automated agent can do that in minutes, how many similar backends are already being skimmed without anyone noticing?
