Manchester Airports Group disclosed on August 27, 2026 that attackers stole customer data covering Manchester, London Stansted, and East Midlands airports. Around 8.7 million customers are affected. Three days later the extortion group FulcrumSec claimed the attack, put the haul at 86GB, and described a method that turns the incident from a breach story into an engineering indictment.

According to FulcrumSec, it obtained airport-specific Iterable API credentials that were exposed in client-side JavaScript.

That is the whole intrusion. Open developer tools, read the page source, take the key, query the marketing platform’s API.

What was taken

MAG says the exfiltrated data relates to car park, lounge, and Fast Track bookings, plus airport Wi-Fi sign-ups, and includes:

  • Email addresses
  • Phone numbers
  • Vehicle registration numbers
  • Postcodes

Customer payment details were not accessed, and MAG says airport operations were unaffected. The company says the attackers demanded a ransom and MAG refused to pay, per BBC News. MAG has not named the group; the FulcrumSec claim is the actor’s own.

FulcrumSec’s account adds detail MAG has not confirmed. The group says the material includes roughly 200,000 records tied to upcoming travel for the remainder of 2026, and a Manchester customer export of about 21.5GB containing consolidated profiles that merge customer identifiers with historical booking activity and marketing segmentation.

Why the “upcoming travel” subset is the dangerous part

Most breach data ages into uselessness. This subset does the opposite — it is a live targeting list with a built-in expiry date the attacker can work against.

If you know a person’s name, email, mobile number, vehicle registration, home postcode, and the fact that they have a car parking booking at Terminal 2 on a specific date, you can construct a phishing message that is functionally indistinguishable from a legitimate one:

“Your Manchester Airport car park booking for [reg] on [date] requires payment re-authorisation. Confirm within 24 hours to avoid cancellation.”

That message contains four facts only the airport should know. It arrives while the recipient is in a genuinely time-pressured travel context, on the phone number they gave the airport. Conversion rates on that campaign will not resemble ordinary phishing conversion rates.

The vehicle registration data is a second-order problem. Registration plus postcode is a strong identity assertion in the UK, useful for vehicle-related fraud, cloning, and social engineering against insurers and the DVLA. It is also a data element most people have never considered as sensitive and will not think to monitor.

The API key problem is not a Manchester problem

An API key embedded in front-end JavaScript is readable by anyone who opens a browser. That is not a vulnerability in a subtle sense — it is the documented, unavoidable behavior of client-side code. Everything shipped to the browser is public.

The failure is not that the key was in the JavaScript. The failure is that the key had broad read access to a backend customer database.

Iterable, like most marketing automation platforms, distinguishes between key types. There are keys intended for client-side use with narrowly scoped write-only permissions — enough to record that a user viewed a page or submitted a form — and there are server-side keys with read access to the customer data store. The second class is never supposed to leave the server.

What appears to have happened here is the single most common API security failure in modern web applications: a developer needed a client-side integration to work, the restricted key did not have the permission the feature required, the full-privilege key did, and it shipped. Nothing exploded, the feature worked, and the key sat in production page source until someone with bad intentions read it.

The controls that catch this

Scope keys to the minimum, then verify the scope from the outside. Do not trust the documentation of what a key can do. Take every key that appears in your front-end bundle and actually attempt a bulk read against the vendor’s API with it. If it returns records, you have found your incident before someone else does.

Scan your own build output. Secret scanning is near-universal in source repositories and near-absent in compiled front-end bundles. The key in this case was in shipped JavaScript, which is exactly where repository-level scanning does not look. Add a post-build scan of the artifact you actually deploy.

Rate limit and alert at the vendor layer. Bulk extraction of 86GB through a marketing platform API is a volume anomaly that the platform can see even when the customer cannot. Marketing automation vendors sitting on tens of millions of consumer records need per-key volumetric baselines and automatic throttling as a default, not as an enterprise-tier feature.

Treat marketing platforms as tier-one data systems. Iterable, Braze, Klaviyo, and their peers hold complete customer profiles, and they are procured, configured, and operated by marketing teams. The gap between where that data sits and where security governance reaches is the structural issue this incident exposes, and it is present at nearly every consumer-facing business.

Audit the third-party JavaScript on your own booking flows. MAG’s exposure came through its own code. Many organizations have equivalent exposure through tag managers and vendor scripts they do not review.

MAG says it contained the risk immediately, engaged specialist advisers, and is working with the relevant authorities. UK regulatory follow-through sits with the ICO; at 8.7 million affected individuals this is among the largest UK data incidents disclosed in 2026, and the client-side credential exposure is the kind of finding that shapes an enforcement outcome.

Sources

FulcrumSec’s claims regarding data volume and access method are the threat actor’s own and have not been confirmed by MAG.