Nobody breached the airport. The credentials were published on its own website.
Manchester Airports Group disclosed on August 27, 2026 that customer data had been taken from Manchester, London Stansted and East Midlands. On September 3, the extortion group FulcrumSec published it.
WHAT ACTUALLY HAPPENED
FulcrumSec did not exploit a firewall, phish an administrator or deploy ransomware. According to the group, it used airport-specific Iterable API credentials that were sitting in MAG's own client-side JavaScript.
Iterable is a marketing engagement platform. The keys that let the website talk to it were shipped to every visitor's browser, readable by anyone who opened developer tools. The data was pulled through the vendor's API. MAG's core network was never touched.
Roughly 8.7 million customers — for the vast majority, email addresses only. The fuller records include phone numbers, postcodes, vehicle registrations, device and IP data, Wi-Fi registrations, and car park, lounge and Fast Track bookings with prices and dates. Nearly 200,000 records allegedly carry upcoming 2026 travel dates.
FulcrumSec claimed 86 GB compressed, 640 GB extracted. It attempted extortion, said MAG appeared unwilling to meet its demands, and published on September 3. MAG says it is "confident that we have taken effective measures to protect our customers."
WHY THIS IS NOT A HACKING STORY
There is no intrusion to detect here. No malicious binary, no lateral movement, no impossible-travel login. Every request was a valid, authenticated API call using a credential the company had handed out itself.
That is what makes secrets in front-end code so dangerous. The exposure is permanent and public — every visitor, every crawler, every archived copy holds it — and the theft looks exactly like normal traffic.
And look at what leaked. Not payment cards. Travel dates, parking bookings, vehicle registrations and phone numbers: the precise ingredients for a convincing "your flight has changed" message, and for knowing which houses sit empty next week.
WHAT TO DO NOW
READ YOUR OWN FRONT END — search your production JavaScript bundles for keys and tokens, because attackers already have.
MOVE THE CALL SERVER-SIDE — any API that returns customer records must be called from your backend, never the browser.
SCOPE AND ROTATE VENDOR KEYS — every SaaS credential should be permission-limited, rate-limited and rotated on your schedule.
WATCH THE VENDOR'S LOGS — if you cannot see API call volume per key at your SaaS platform, you cannot detect this theft.
Attackers do not need to break in when you leave the keys outside.
When did you last read your own website's JavaScript the way an attacker would?