Breach · Access Control

FulcrumSec Claims Manchester Airports Hack and Theft of 86 GB of Data

August 31, 2026 · 6 min read

An extortion group called FulcrumSec claims it walked into Manchester Airports Group's customer data environment by reading an API key out of client-side JavaScript. If that claim holds up, the entire incident comes down to one secret that should never have been visible to a browser. The breach exposed data for approximately 8.7 million customers across Manchester, London Stansted, and East Midlands airports, MAG refused to pay the ransom, and now FulcrumSec says it intends to publish both the data and a technical writeup of how it got in. That last part is worth watching closely.

What actually happened

MAG's systems detected unauthorized access on August 25, 2026, and the company publicly disclosed the incident on August 27, 2026. The initial disclosure confirmed that a quantity of customer data had been accessed, specifically records related to car park, lounge, Fast Track bookings, and airport Wi-Fi registrations. Compromised fields included email addresses, phone numbers, vehicle registration numbers, and postcodes. MAG was clear that no payment card or banking details were accessed, and that airport operations, passenger safety, and aviation security were unaffected throughout. The company suspended its online Manage My Booking service as a precaution, notified affected customers directly, and reported the incident to relevant authorities. The ICO confirmed it received a breach report from MAG and was assessing the details, though no formal enforcement action had been announced as of August 29, 2026.

MAG also received a ransom demand and rejected it. Two days after MAG's disclosure, on approximately August 29 to 30, 2026, the extortion group FulcrumSec publicly claimed responsibility and told BleepingComputer it had stolen approximately 86 GB of data. FulcrumSec's claimed method of entry is the detail that makes this incident particularly instructive: the group says it obtained access using Iterable API credentials that were exposed in client-side JavaScript on MAG's own web properties. Iterable is a customer engagement and messaging platform, which explains how the group reached customer contact and booking data rather than payment systems or operational infrastructure.

BleepingComputer reviewed samples provided by FulcrumSec and found they contained more detailed customer, booking, and travel information than MAG's initial disclosure described. One traveler record was independently validated by cross-referencing it with a known booking. FulcrumSec also claims the stolen data includes nearly 200,000 records tied to upcoming travel during the remainder of 2026, complete with dates, times, and booking details linked to personally identifiable information. That category of data, forward-looking travel itineraries with PII attached, carries a different risk profile than historical contact records. MAG has confirmed approximately 8.7 million customers were affected across its three airports, though the majority had only their email addresses compromised. FulcrumSec's 86 GB figure has not been independently confirmed by MAG or any external forensic party as of August 30 to 31, 2026.

Why this should matter to you even if you don’t run Manchester Airports Group

Even if you run nothing that looks like an airport, this incident maps to a pattern that shows up across a wide range of web-facing organizations. The alleged vector, a third-party platform API key embedded in JavaScript that executes in the browser, is one of the more common ways sensitive credentials end up accessible to anyone willing to open developer tools. Customer engagement and marketing platforms like Iterable often require some form of authentication token to function in the browser context, and when those tokens carry write or broad read permissions, the exposure radius is large. The instinct to treat a client-side API key as low risk because "it's just for sending emails" tends to underestimate what a sufficiently privileged token can reach inside the platform it authenticates to.

MAG handles roughly 66.3 million passengers per year across its three airports, which makes the customer dataset large enough that even partial exposure produces significant numbers. The breach affected approximately 8.7 million customers. For most of them, the immediate exposure was their email address, which on its own is a phishing enabler. For a smaller subset, the exposure extended to phone numbers, vehicle registration plates, postcodes, and in FulcrumSec's claimed dataset, upcoming travel itineraries. That combination is enough to craft a convincing targeted phishing message or a smishing campaign that references real booking details, and MAG advised customers to follow NCSC post-breach guidance and stay alert for exactly that kind of follow-on activity.

The operational and reputational context here is also worth thinking through. Airport operations were unaffected, and MAG made that clear early. But the customer trust equation for any organization that collects travel and identity-adjacent data is fragile in a different way than it is for, say, a retail loyalty program. People hand over vehicle registration numbers and travel schedules because they have to, and they expect that data to be handled carefully. When a group like FulcrumSec threatens to publish not just the data but a detailed technical account of how the intrusion worked, the secondary damage to organizational credibility tends to compound over time regardless of whether the ransom was paid.

The control that would have blunted it

The control category here is access control, specifically secrets management and the principle of least privilege applied to third-party platform credentials. The core recommendation is straightforward: API keys and tokens that authenticate to external platforms should never be embedded in code or markup that executes in the browser. The browser is a fully untrusted environment. Any credential that appears there can be extracted by anyone who loads the page. If a customer engagement platform like Iterable requires some form of token for browser-based functionality, that token should carry the minimum permissions necessary for that specific frontend function, ideally scoped to write-only event submission with no ability to query or export customer records. Broad-access API keys belong on the server side, never in client-side JavaScript.

In practice, this means building a server-side proxy layer that holds the privileged credential and exposes only narrow, validated endpoints to the frontend. The frontend calls your own API, your server authenticates to Iterable or whatever third-party platform is involved, and the actual API key never leaves your infrastructure. This adds a layer of complexity and a component to maintain, and it does introduce a potential single point of failure if that proxy layer goes down. Those are real tradeoffs. The operational overhead is generally worth it given the alternative, which is leaving broad-access credentials readable by any user who opens browser developer tools.

Cyber insurers have been paying closer attention to secrets management practices over the past few years, partly because this class of exposure keeps producing large-scale breaches. Many insurers now include questions about secrets scanning in their application and renewal questionnaires, asking whether organizations run tools that detect hardcoded credentials in source code and deployed assets. A mature secrets management posture includes scanning both your code repositories and your deployed web assets for exposed tokens, rotating credentials on a defined schedule, and maintaining an inventory of which API keys exist, what permissions they carry, and which systems they can reach. That inventory is also the foundation for a faster incident response when something goes wrong, because you can quickly identify what a compromised credential could have accessed. Without that inventory, the scoping phase of an investigation takes much longer and produces less confident answers, which is exactly the position MAG appears to be working through right now.

Strondex's Access Control practice helps organizations audit third-party platform credentials, enforce least-privilege scoping, and establish the secrets management inventory that cyber insurers increasingly expect to see.