Manchester Airports Group disclosed on August 27, 2026 that an unauthorized third party had stolen customer data affecting roughly 8.8 million people. The breach covered car park bookings, lounge reservations, Fast Track purchases, and WiFi sign-ups across Manchester, Stansted, and East Midlands airports. The attacker, a group calling itself FulcrumSec, made a claim that turned out to be verifiable: they did not hack anything. They read an API key out of the website's JavaScript.
How the keys ended up in the browser
MAG runs three airport websites as Next.js applications served through CloudFront. The JavaScript bundles shipped to visitors contained a config object for Iterable, a marketing automation platform. That config included API keys, one per airport, embedded directly in the code that every visitor's browser downloaded and executed.
The keys were not in the HTML source or the initial page data. They lived inside one of roughly ninety content-hashed chunk files that the page loads dynamically. That made them invisible to casual inspection and, apparently, to whatever security scanning MAG had in place. A grep of the page source finds nothing. You have to pull the chunk files and search those instead.
When you do, the keys are there. A 32-character hexadecimal string for each airport, sitting in a config object that feeds API calls made directly from the browser. The site's own code sends a GET request to Iterable's user profile endpoint with the email address and the key, and reads back a user object. It is a server-side credential doing a server-side job, executed from inside the browser on every normal page load.
Four years without rotation
The Internet Archive's CDX API indexes JavaScript files, not just homepages. Checking MAG's app chunks across all three domains reveals the timeline. East Midlands received its key on June 23, 2022. Stansted got theirs on June 28, 2022. Manchester's appeared on July 11, 2022. The exact same values appear in every capture through August 2026.
That is more than four years without a single rotation. Three distinct keys, one per airport, present in every snapshot for the entire period. Anyone who inspected the page source on any day between June 2022 and August 2026 could have taken the key. FulcrumSec are simply the ones who admitted it.
Stansted's key went empty by August 25, two days before MAG went public. Manchester's was emptied on August 27, the day of the disclosure. That timeline suggests MAG found and killed the keys before announcing the breach, which is standard incident response. But it also means the keys were active for four years, and there is no way to determine from the outside who else accessed them during that window.
What the keys could actually do
Iterable's API documentation, published unauthenticated, lists 131 endpoints. Of those, 98 require server-side keys. The endpoints that MAG's JavaScript was calling, user profile lookups and event tracking, are tagged as server-side only in Iterable's spec. A browser-scoped key would have failed silently on the profile lookup, and MAG's code swallows that error in a catch block that logs a warning and continues.
But the keys that were exposed appear to have been server-side keys, based on the fact that they actually worked for profile retrieval. That gave an attacker read access to customer records by email address. More critically, it gave access to Iterable's export endpoints, which can return entire tables without pagination. One request to the export endpoint with dataTypeName set to "user" returns every customer profile. The purchase, customEvent, emailSend, emailOpen, and emailClick data types return transaction histories, booking records, marketing messages, and IP addresses with browser user agent strings from email tracking pixels.
The destructive half of the API was equally accessible. The same key could delete users, delete lists, trigger GDPR erasures, mass-rewrite profiles, and change email addresses. FulcrumSec did not appear to use those capabilities, but for four years the ability to wipe MAG's customer database was a view-source away.
What the stolen data actually contains
The exposed records go beyond what MAG collects directly from customers. Every record carries Iterable's own derived fields: region codes inferred from IP addresses, phone types parsed from numbers, email domains split from addresses, and machine learning scores that Iterable's platform generates internally. One field, brandAffinityLabel, is a sentiment score that Iterable computes, not something a customer provides.
The records also carry Iterable's subscription state, list IDs, channel IDs, and message type preferences. They appear in exactly two places: the response from the user profile endpoint and the output of Iterable's export function. The data shape, with nested objects duplicated as flattened dotted keys, is characteristic of Iterable's export format.
FulcrumSec reported roughly 86 gigabytes compressed, expanding to approximately 640 gigabytes. That includes a 21.5 gigabyte Manchester customer export and about 200,000 records covering upcoming travel in 2026 with dates, times, and booking references tied to names and vehicle registrations. That last category is the one that matters most. An email address leaking is routine. A record showing that a named person with a specific car registration is flying on a particular date is a physical security concern.
The broader lesson about client-side secrets
The core failure here is not that MAG used Iterable or that their marketing integration had a bug. It is that a server-side API key was shipped to the browser in a JavaScript bundle and sat there for four years without anyone noticing. The key had permissions that exceeded what the browser code needed, and no one rotated it.
This is not an exotic attack vector. Opening browser developer tools and reading the JavaScript is not hacking. It is what every front-end developer does daily. The tools to search chunk files for secrets exist and are free. The fact that the keys survived four years suggests that MAG's security posture did not include inspecting their own JavaScript bundles for embedded credentials, a gap that many organizations share.
For any team shipping API keys in client-side code, the question is not whether someone will find them. It is whether the key has the minimum permissions required, whether it is rotated regularly, and whether someone is actually watching for it in the published bundles.