decrypted · 9 september 2026 · vulnerabilities and patching · uk policy and law · surveillance and privacy

The Manchester Airports breach that needed no exploit

Manchester Airports Group disclosed on 27 August that an unauthorised third party had accessed customer data tied to Manchester, Stansted and East Midlands airports. In the fortnight since, the picture has sharpened: the extortion group FulcrumSec has published the stolen records on its leak site, an independent technical write-up this week traced exactly how the attacker got in, and UK law firms have begun organising group litigation against MAG. None of it required a software vulnerability, a phishing email or stolen login credentials. It required someone to open a browser's developer tools.

A key left in the shop window

Each of the three airports' websites called a marketing platform, Iterable, directly from the browser to personalise pages and track visitors. To do that, the pages embedded an Iterable API key inside the JavaScript that every visitor's browser downloads and runs. A technical analysis published on 7 September found that the Manchester key had been sitting in public view since at least 23 June 2022, over four years, and had never once been rotated. It is the digital equivalent of taping the filing cabinet's master key to the inside of a shop window: visible to anyone who looked, and never once changed.

FulcrumSec said it simply read the keys out of the page source, one per airport, and pointed them at Iterable's own bulk-export endpoint, a single request that returned MAG's entire customer database as a CSV file. Reported figures for the resulting haul vary a little, somewhere between roughly 550GB and 640GB uncompressed depending on the source, but the substance is consistent: around 8.7 million customer profiles, including names, emails, phone numbers, postcodes, IP addresses and vehicle registration plates, plus close to 200,000 future bookings complete with travel dates, exactly the detail needed for convincing phishing.

Why this is a design failure, not a hacking story

The flaw wasn't that a secret leaked. It's that a secret which was always going to be visible was scoped as if it never would be. Platforms like Iterable offer separate credential types for this reason: broad server-side keys for backend integrations, and narrowly scoped, browser-safe tokens for anything shipped to a visitor's device. MAG's implementation used the server-side key in client-side code, handing every visitor the keys to the warehouse instead of a fitting-room token. Secure by Design means treating the browser as hostile by default and treating credential rotation as a scheduled task, not an incident response.

For any UK organisation running a marketing, analytics or engagement platform, the lesson translates directly: audit what your public-facing pages actually send to the browser, confirm every embedded key is scoped for that exposure, and rotate on a calendar rather than after a breach. Secrets-scanning tools that watch a site's own shipped JavaScript, not just its source repositories, would have caught this on day one and every day since. MAG has confirmed contacting affected customers with fraud warnings but has not addressed FulcrumSec's specific technical claims, and the ICO has confirmed it is assessing the breach report.

Also this week

Sources

If your organisation needs a second pair of eyes on what your own website is quietly handing to every visitor's browser, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.

Prefer to listen? Decrypted on Apple Podcasts, or paste the podcast feed into any app.