Manchester Airports breach: a marketing API key exposed in client-side JavaScript

The security control that failed at Manchester Airports Group was not a firewall, a server, or an endpoint agent. If the extortion group FulcrumSec is telling the truth about how it got in, the breach turned on a single credential that the airports' own websites handed to every visitor's browser. No intrusion tripped an alarm on MAG's infrastructure because, in the technical sense that matters to a defender, there was no intrusion. Someone opened the developer console, read a key that was sitting in the page's JavaScript, and used it the way it was designed to be used.

MAG confirmed on August 27 that a data breach affected 8.7 million of its customers. The group runs Manchester Airport along with London Stansted and East Midlands, and says the exposed data covers car park, lounge, Fast Track, and airport WiFi registrations, that most affected customers had only an email address exposed, and that no payment card or bank data was involved. FulcrumSec claimed responsibility two days later, put the haul at 86GB, and named its method: airport-specific Iterable marketing API credentials exposed in client-side JavaScript. Those specifics are the group's account, not MAG's. BleepingComputer independently validated one traveller's record against a real purchase history, which tells us the sample data is genuine even though the exact volume and method remain the attacker's claims and MAG has declined to address them.

The credential was published, not leaked

Language matters here, because "leaked API key" makes people picture a mistake in a private repository. That is not what a client-side key is. Marketing and analytics platforms like Iterable run partly inside the visitor's browser so they can track events and personalize content, and to do that they need a credential that lives in the page. A key shipped to the browser is not exposed by accident. It is published to the entire internet by design, readable by anyone who presses F12.

That is fine when the key can only do trivial, write-only things: record that a page was viewed, add someone to a list. It becomes a breach when the same class of platform issues one credential that can also read and export the customer database behind it, and an integration drops that broader key into the front end. The distinction between a browser-safe public token and a server-only private key is a line every one of these platforms draws, and it is the line that decides whether a published credential is a shrug or a catastrophe. On the evidence, the credential in play here sat on the wrong side of it.

So the useful question after a breach like this is not "who attacked us." It is "what can every key in our shipped JavaScript actually do, and who decided that." Most organizations cannot answer it, because no single team owns the inventory of secrets embedded in production front-end bundles. Application security scans source code; it rarely scans the minified JavaScript that actually reaches users, which is where a build step or a third-party tag can quietly introduce a key nobody reviewed.

Why every server-side control missed it

Walk this breach past the controls a typical security budget is spent on and watch them all abstain. The data did not leave through MAG's servers, so an endpoint agent watching those servers saw nothing anomalous. It did not cross MAG's network perimeter, so a firewall or web application firewall had no request to inspect. The API calls went from the attacker straight to Iterable's cloud, authenticated by a valid key, and looked exactly like legitimate traffic to the marketing platform.

The only two places this was ever visible are the two most teams ignore. The first is before the key ever ships, in continuous integration, where a secret scanner run against the built bundle rather than the source tree would flag a read-capable credential heading for production. The second is after the key is abused, in the audit log of the SaaS platform itself, where a sudden bulk-export pattern from a new network would stand out. Almost nobody pipes their marketing or analytics platform's API logs into the SOC, which means the one sensor with a clear view of this attack is usually switched off.

A vulnerability class with no CVE and no patch

This is why a breach like this slips past vulnerability management entirely. There is no CVE to track, no advisory to read, no version number to compare against. A program that measures itself by patch latency has no line item for "a valid credential doing valid things," and so it never counts this surface at all. The exposure is not a bug in Iterable and not a flaw a scanner will rate CVSS 9.8. It is a scoping and placement decision made once during an integration and then forgotten, and it stays exploitable for as long as the key is valid and no one thinks to look.

It also breaks the reflex the industry has trained into everyone. There is nothing to patch. Rotating the exposed credential is necessary, but it is a tourniquet, not a cure, and it does nothing about the records already taken while the key was live. You have to treat every row that credential could reach as already gone, then remove the reason the key was reachable in the first place: pull the read-capable secret out of the browser, put a narrowly scoped public token in its place, and move any privileged call behind your own server, where you can log it, rate-limit it, and revoke it.

What to do this week

You do not need to be an airport to have this problem. Any site running a marketing, analytics, or personalization SDK is shipping credentials to browsers right now, and the failure mode is identical whether you handle eight million customers or eight thousand.

• Inventory the secrets in your shipped front end. Run a secret scanner against your built, minified JavaScript, not just your source repository. The key that breached MAG would never appear in a source-only scan if a build step or tag manager injected it.

• Check the scope of every browser-delivered key. For each third-party platform, confirm the credential in the page is the public, write-only variant and cannot read or export data. If a single key does both, you have the MAG condition. Rotate it and split the roles.

• Turn on the one sensor that can see abuse. Pull your SaaS platforms' API audit logs into your monitoring and alert on bulk reads, exports, and calls from new IP ranges or autonomous systems. This is the only place a valid-but-abused key leaves a trace.

• Put privileged calls behind your own API. The browser should talk to your server, and your server should hold the powerful credential. That gives you a chokepoint to authenticate, throttle, and audit, none of which is possible once the key is in the page.

• Treat exposed as exfiltrated. A read-capable key that sat in public JavaScript should be assumed used. Scope your incident response to everything it could reach, not to the evidence you happen to have.

The uncomfortable takeaway is that the strongest server security in the world would not have changed this outcome. The perimeter that mattered was the boundary of a third-party API, defined by a credential that a marketing team wired in and a security team never saw. Until the question "what is in our JavaScript, and what can it do" has an owner and an answer, this is a breach any organization can have without a single one of its servers being touched.