Manchester Airports Group — 8.7 million customer records taken, allegedly via API keys exposed in website JavaScript

What happened

Manchester Airports Group is the UK’s largest airports group, running Manchester, London Stansted and East Midlands airports and handling upwards of 60 million passengers a year. On Tuesday 25 August 2026 its security team identified unauthorised access to customer data, following an intrusion that appears to have taken place over the preceding weekend of 22 August. MAG contained the access and disclosed publicly on Thursday 27 August, saying it had “immediately contained the risk” and had “been working with specialist advisors and taking appropriate steps to protect our customers and systems.”

The data involved sat behind MAG’s commercial customer services rather than anything to do with flying: car park bookings, airport lounge access, Fast Track security purchases and airport wifi sign-ups, across all three airports. Roughly 8.7 million people were affected, but the exposure was not uniform. For the vast majority of them what was taken was an email address and nothing more. Phone numbers, postcodes and vehicle registration plates were exposed for smaller subsets, alongside IP addresses, browser user-agent strings and purchase history. The proportions in the published dataset make the point: 108,077 vehicle registrations and 2.48 million purchase records against 8.67 million customer profiles. MAG has been consistent that no bank or payment card details were held in the affected system, and that flights, airport operations and aviation security were unaffected at any point.

Over the following weekend an extortion group calling itself FulcrumSec claimed the intrusion, stating it held around 86 GB of compressed data. FulcrumSec emerged in 2025 as a financially motivated actor and has previously claimed breaches at Novo Nordisk, LexisNexis and Arup Group, among others. MAG confirmed that it had received a ransom demand but declined to share further detail. It did not pay. FulcrumSec has since stated that MAG failed to meet its demands, and reporting is consistent on the point, though the refusal itself has been characterised by the attackers rather than announced by the company. By 3 September FulcrumSec had published the material on its leak site, and Have I Been Pwned loaded the dataset on 2 September at 8.8 million accounts. The two headline figures are not in conflict: 8.7 million is the customer count MAG and the attackers both use, while 8.8 million is HIBP’s count of parsed email addresses.

The published archive is unusually well itemised. FulcrumSec’s own accounting puts it at approximately 8.67 million customer profiles, 2.48 million purchase records, 1.16 billion marketing events, 461,433 SMS messages tied to bookings, 108,000 vehicle registrations and around 190,000 upcoming bookings, including more than 142,000 records linking a passenger email address to a vehicle. The group said it had withheld some future travel information on the grounds that publishing it would enable stalking and burglary, which is a self-serving framing but does describe the risk accurately.

On the volume, the sources do not agree and it is worth being precise. The 86 GB figure is the compressed archive and is consistent across reporting. Uncompressed, FulcrumSec have claimed roughly 549 GB, SecurityWeek reported approximately 550 GB, and BleepingComputer’s later update put the extracted total nearer 640 GB. The compressed number is the firm one.

How it worked

One caveat has to sit at the front of this section, because it changes how much weight the rest of it can carry. The account below is FulcrumSec’s. MAG has confirmed that unauthorised access occurred and that data was taken, but it has not publicly confirmed the method, and Iterable has not commented. What follows is a claim by the attacker, not an established forensic finding, and it should be read that way until MAG or a post-incident report says otherwise.

FulcrumSec’s account is that they found API credentials for Iterable, a customer engagement and marketing automation platform, embedded in the client-side JavaScript of all three airport websites. Their emphasis was on how ordinary the location was. In their words, the keys “were not found on some obscure subdomain” and “all three of these were on the sites’ root domain,” such that any of the millions of visitors to those sites “could have right-clicked ‘inspect’ and seen the keys.”

If accurate, that is the whole intrusion. Client-side JavaScript is, by definition, public. Every byte of it is delivered to the browser of every visitor, which means a credential placed there is not leaked, it is published. There is no exploit chain to describe, no malware, no phishing, no credential stuffing and no multi-factor bypass, because none of those things were needed. The attacker read a key from a public web page and then used it the way keys are meant to be used.

What the key reached is the part that determined the blast radius. Iterable is not a peripheral system. A customer engagement platform holds the customer graph: profile records, contact details, consent state, and the full event history of what each person has been sent, opened and bought. A credential with read scope across that platform is a credential with read scope across the customer base. The 1.16 billion marketing events in the published set is the number that gives this away. That is not the yield of a narrowly scoped key. It is what you get when a key can read the whole event history for everybody.

The uncomfortable symmetry with the Klue compromise earlier in the year is that both incidents ended with an attacker querying a legitimate SaaS platform through a valid, authorised credential, generating traffic that looked entirely normal at the point it was received. Klue reached that position by stealing OAuth tokens from a compromised vendor. MAG’s attacker, on this account, reached it by reading a key off a public website. Different route, same destination: an authorised caller pulling a customer database through an interface working exactly as designed.

Timeline

• 2025 — FulcrumSec emerges as a financially motivated extortion group, later claiming victims including Novo Nordisk, LexisNexis and Arup Group.
• Weekend of 22 August 2026 — Unauthorised access to MAG customer data takes place.
• 25 August 2026 — MAG’s security team identifies the unauthorised access and contains it, engaging specialist advisors.
• 27 August 2026 — MAG discloses publicly, stating that no payment details were held in the affected system and that operations and aviation security are unaffected.
• Around 30 August 2026 — FulcrumSec claims responsibility, stating it holds approximately 86 GB of compressed data, and signals an intent to leak.
• Late August to early September 2026 — MAG receives a ransom demand and declines to pay.
• 2–3 September 2026 — FulcrumSec publishes the dataset on its leak site, withholding a portion of future travel data. Have I Been Pwned adds the breach at 8.8 million accounts on 2 September.

What defenders should learn

The first lesson is the bluntest one available in this catalogue. A secret in client-side code is not at risk of exposure. It is exposed, continuously, to everyone who has ever loaded the page, from the moment it ships. The correct mental test is not “could an attacker find this” but “can a customer see this,” and the answer for anything in front-end JavaScript is always yes. The corresponding control is unglamorous and cheap: run secret scanning against your own rendered front end, from the outside, on a schedule, the same way you would run an external vulnerability scan. On FulcrumSec’s account, three public websites belonging to the UK’s largest airports group carried live platform credentials on their root domains, and nobody on the defending side was looking.

The second lesson concerns which systems get treated as sensitive. Marketing and customer engagement platforms are rarely on the list of crown jewels. They are procured by marketing teams, integrated by web developers, and reviewed, if at all, as a data protection question rather than a security one. Yet Iterable held the identities, contact details, locations, vehicles and behavioural history of 8.7 million people. On the evidence of what was published, it was the single richest customer dataset MAG had. If your inventory of critical systems is organised around finance, operations and core IT, and your marketing stack is not on it, you have the same gap.

The third is scope, and it is the same lesson Klue taught from the other direction. The question is not only who holds a credential into your customer platform, but what a single credential is permitted to read once it is used. A key scoped to the specific operations a website genuinely needs, sending a transactional email, say, cannot bulk-export 1.16 billion events. A key scoped for developer convenience can. Nothing about the integration required the generous scope. It was chosen because it was simpler, and the cost of that simplicity became visible only once someone else was holding the key.

The fourth is a point of honesty about framing. This was widely covered as an attack on UK airports, with the implication of a threat to critical national infrastructure. It was not. Nothing operational was reached, no flight was affected and aviation security was never in question. It was a marketing database breach at a company that happens to run airports. That distinction matters, because the controls that would have prevented it are application security and SaaS credential scoping, not operational technology segmentation. Reaching for the wrong lesson because the victim is a dramatic one is how organisations end up funding the wrong programme. Compare this with the Minnesota water utilities attack, which genuinely was an operational technology incident, and the difference in what defenders should take away is total.

The last lesson is about the decision MAG got right. The company refused to pay, and the data was published as a consequence. That is the expected outcome, and it is still the correct decision. Payment buys a promise from an extortion group that has every incentive to break it, and no mechanism exists to verify deletion. What refusal costs is a bad fortnight of headlines and a large customer notification exercise. What it protects is the economics that make the next 8.7 million records worth stealing. MAG’s remaining exposure is now fraud and phishing against its customers, which is a communications and monitoring problem, and a serious one, but a bounded one. Read alongside the Ceva Logistics breach in late July, where one vendor compromise put seven named consumer brands into customer notification at once, the pattern since June is consistent: the data that gets taken increasingly sits in a platform that the breached organisation does not run, reached through a credential that was working exactly as intended.