There was no exploitation in this case. The security vulnerability was not exploited, there was no malware that was run, and there were no clicks made on things they shouldn’t have clicked. The log-in information for the airports were left out in the page source of the website.
The Manchester Airports Group manages the Manchester, Stansted, and East Midlands airports. They found out about the unauthorised access on August 25, 2026. Two days later, they reported the hack, while the leaking of the data occurred on September 3.
What The Operator Has Actually Confirmed
Around 8.7 million clients are impacted by this. The verified data includes email addresses, contact phone numbers, vehicle registration details, and postcodes.
This data was sourced from bookings for car parks, lounges, Fast Track, and airport WiFi. MAG has stated that there was no disruption to flights.
The firm further stated that they had been given a ransom note, but they declined to pay. This has even been admitted by the extortionists.
This forms the verified perimeter of this incident. All information beyond this point comes from the hackers themselves.
The Entry Point Is Still Only A Claim
It is claimed that analysts managed to retrieve airport-specific Iterable API keys exposed through client-side JavaScript. Iterable is an engagement platform, which is one of the services that store marketing and booking data for companies.
They were quite precise about how they acquired the keys. The keys in question were not hidden somewhere on a subdomain, according to them, but instead were located at the root domains of all three airport websites.
At present, MAG neither confirms nor denies that claim. Therefore, the only technical part of this data leak that is worth considering is an attacker’s description of their actions.
So be it. The attack sounds plausible and specific, although not verified yet.
What Airports Hold About You
Numbers That Come Only From The Criminals
The volume figures are worthy of investigation because they have changed.
To start with, it is estimated that there was 86 GB of data. Days later, the group came back to clarify that they had compressed their own data, while the full extent of the files came to around 640 GB. Third-party reports state that the figure is closer to 550 GB.
Three different numbers, all about the same breach, all from the same group, none of which have been confirmed by MAG.
The number of records falls into the same category. Apart from the customer figures, the group states that there were 1.2 billion marketing activities, 2.5 million transactions, 461,000 SMS messages, 108,000 license plates and roughly 191,000 future reservations.
Future reservation is the record that makes the most difference to the customers. It is valuable for a scammer to know where and when someone is taking off from an airport, while old emails aren’t of much use.
Refusing To Pay, And What Comes Next
MAG has contacted the UK Information Commissioner’s Office, which has confirmed receipt of the report and is assessing it. No official investigation has yet been announced.
This case proceeded as expected after the refusal to pay. Refusal doesn’t stop exposure, it merely eliminates any pretense that the payment was ever about deletion.
We’ve already analyzed this kind of risk assessment with the refusal of an offer by a Swiss rail company for $12.3 million.
The Control That Was Never Tested
It is useful to be clear about the nature of this event.
No endpoint defenses were compromised, as no code was run. This was a data access issue. A person had access to a customer database through a key that was made public on the open internet, and the database was located on a third party system, not directly managed by MAG.
This is relevant to how the regulator will ask its questions. The organization in such a case will have to explain the controls, what they protected against, and what the attacker had access to within the boundary they entered. Detection telemetry tells you what was observed. It does not tell you what was impossible.
The space between these two things is where breach response becomes challenging. Monitoring provides a record of the event. Enforcement provides proof of the structural impossibility of the event.
Conclusion: The Credential Was Public. The Database Was Not.
The defining lesson from the Manchester Airports Group breach is that an attacker may not need to break a security control when the credential protecting the next boundary has already been published.
MAG has confirmed that customer information relating to Manchester, Stansted, and East Midlands airports was accessed by an unauthorized third party, affecting approximately 8.7 million people. The confirmed data includes email addresses, phone numbers, vehicle registrations, and postcodes, while airport operations and aviation safety were not disrupted.
MAG has not publicly confirmed the technical entry point. However, the attackers’ claim that airport-specific Iterable API keys were exposed in client-side JavaScript has strong independent technical support. Historical captures show separate keys present in the public source of all three airport websites for years, and the permissions associated with the relevant API access are consistent with the type of data reportedly taken.
If that route is ultimately confirmed, the failure is striking because nothing needed to be exploited. The browser was simply given a credential that was never supposed to become public.
Why This Threat Matters
- A secret in client-side code is no longer a secret. Anything delivered to a visitor’s browser should be treated as publicly recoverable.
- No CVE is required for serious data loss. A valid credential with excessive access can provide a cleaner route to sensitive information than exploiting vulnerable software.
- Long-lived keys accumulate invisible risk. A credential exposed for years creates an access window whose true history may be impossible to reconstruct without equally long-lived provider logs.
- Third-party platforms can amplify one mistake. A marketing or engagement service may centralize customer records from multiple brands or locations behind a small number of credentials.
- Operational continuity does not mean confidentiality held. Flights continued normally while customer data was still lost.
- Extortion without encryption changes what defenders see. There may be no malware outbreak, outage, or dramatic endpoint event to mark the moment the breach occurred.
Where Defensive Control Must Operate
For this attack shape, the first defensive control belongs in application and secret governance.
Server-side API credentials should never be embedded in browser-delivered code. Keys should be scoped to the minimum required permissions, rotated regularly, inventoried across applications, and monitored for unexpected use. Client-side builds should be reviewed automatically for secrets before deployment, and third-party API access should be treated as part of the organization’s own security boundary.
Where exposed customer data or API access later contributes to abnormal account activity or privileged identity misuse, Xcitium ITDR becomes relevant at the identity layer.
The important distinction is that identity monitoring addresses the consequences of later abuse. It does not replace preventing the credential from becoming public in the first place.
Rotate the Key. Then Question the Architecture.
Revoking an exposed credential closes the immediate access path, but it does not answer how long the key was public, who may have copied it, what data it could reach, or whether similar credentials remain elsewhere in the estate.
The larger lesson is simple: infrastructure can be external, applications can be public, and APIs can be legitimate. The credential joining them still has to remain private. If the secret is published with the application, the access boundary has already failed before an attacker sends the first request.
