Manchester Airports Group runs Manchester, Stansted and East Midlands airports, and its websites handle car park bookings, lounge access, Fast Track security passes and airport WiFi sign-ups. Somewhere in the JavaScript that runs those websites sat three API keys for Iterable, the marketing platform MAG uses to send booking confirmations and promotional email. According to Scott Helme's technical breakdown, those keys had one intended purpose: recording when a customer clicked a link in a marketing email. What they actually carried was server-side, read-write access to MAG's entire Iterable customer database - full profiles, purchase history, booking references, and the ability to delete or overwrite records outright. As Helme put it, "email click tracking was given a credential scoped to the entire customer database, in order to record a click."
No exploit required
There was no vulnerability to chain and no authentication to bypass. A visitor only had to open their browser's developer tools, load the JavaScript bundle any airport website sends to every device that visits it, and read the key out in plain text. The Register's coverage notes the keys weren't even hidden inside minified HTML - they sat in readable JavaScript files, the kind any browser downloads automatically and any competent engineer would think to check first. Iterable's own documentation warns against exactly this: never embed a server-side key in client-side code, because anything shipped to a browser is public by definition. That warning had apparently gone unheeded since somewhere around 2022, which by MAG's own account put the keys in the open for more than four years before anyone acted on it.
Found by the people who used it
The keys weren't flagged by an internal audit or a bug bounty researcher acting in good faith. An extortion group calling itself FulcrumSec found them first, and Helme's write-up only exists because he reconstructed the group's own account of what it did - and confirmed, key by key, that everything FulcrumSec described checked out. Security Affairs reports the group went on to leak data on the roughly 8.8 million people affected after MAG declined to pay. That the verification came from the extortionists' own claims, rather than from MAG catching the exposure itself, is the part that should worry other organisations most: the keys were discoverable by anyone who looked, for years, and the first people to look with bad intent didn't need to try very hard.
What "read/write to the whole database" actually meant
Because the keys carried full server-side scope rather than the narrow permission the click-tracking use case needed, whoever held them could pull complete customer profiles by email address, export the underlying database in bulk, and read purchase and booking history including forward travel dates, times and reference numbers. The write side was just as broad: individual records or entire lists could be deleted, profiles could be mass-rewritten, and email addresses on file could be changed outright. None of that capability had anything to do with counting link clicks. It existed only because nobody scoped the key down to the one thing it was supposed to do.
- Treat every credential shipped to a browser, mobile app or any other client-side surface as public - if it can be read out of a JavaScript bundle, assume it already has been.
- Scope API keys to the narrowest permission the integration actually needs; a click-tracking pixel should never hold read/write access to a full customer database.
- Rotate vendor and marketing-platform keys on a schedule, not only when a vendor forces it - four years without rotation is what turned a scoping mistake into an 8.8 million-person breach.
- Audit your own public JavaScript bundles for embedded secrets today; it costs nothing more than opening developer tools, which is exactly how this one was found.
- Ask every marketing, analytics and email vendor integration on your estate what permission level its credential actually carries, not what you assumed it was issued with.
This breach didn't need a zero-day, a phishing email or a single line of exploit code - just a credential nobody scoped down and nobody rotated. If you'd like help auditing what your own client-side code is quietly exposing, email sales@halfteck.com.