Last week Manchester Airports Group disclosed that attackers had breached systems holding car park, lounge, Fast Track booking, and in-terminal Wi-Fi sign-up data across Manchester, London Stansted, and East Midlands airports. On 3 September the extortion group published roughly 550 GB of data after MAG declined to pay. The exposed records cover around 8.8 million people and include email addresses, phone numbers, vehicle registrations, and postcodes. Airport operations were unaffected.
The attackers claim they used administrative keys for a third-party marketing platform that were exposed in client-side JavaScript. MAG has confirmed the data sat in a database hosted by a third party and is investigating how the keys were exposed. That method rests on the attacker’s account rather than a regulatory finding, but the claim is specific and plausible.
The Failure Was Not Sophisticated
Client-side JavaScript is public by definition. Every visitor’s browser downloads it, and reading it requires nothing beyond the developer console built into that browser. A credential placed there is not hidden, it is published.
This is a recurring pattern rather than an unusual lapse. Marketing platforms, analytics tools, and booking integrations get wired up under time pressure by teams whose remit is conversion rather than security. A key gets pasted into a frontend script because that is the fastest way to make it work, and it functions perfectly, which is why nobody revisits it. The consequence is a compromise sitting entirely outside the perimeter most organisations spend their budget defending. No firewall or endpoint agent was relevant. The credential was in the shop window.
Refusing to Pay Was Right, and It Still Hurt
MAG did not pay, and operations continued without disruption. That was the correct call, and it denied the group its revenue.
But publishing the data was itself the message. Releasing nine million records for free is not only retaliation against one victim, it is a demonstration aimed at every organisation watching. The people bearing the consequence are customers who had no part in the decision.
The lesson for smaller organisations is that a ransom decision is not the same as an incident plan. MAG could refuse because only data was at risk, never operations. A firm facing operational encryption is in a different position, and the time to work out which situation you would be in is before it arrives.
Where To Begin
Start with the exposure MAG had. Open your own website, view the page source and loaded scripts, and search for anything resembling a key, token, or secret. This costs an hour and shows you exactly what an attacker sees. Anything found must be rotated, not merely removed.
Extend that to the platforms behind those scripts. Marketing automation, booking systems, and analytics tools accumulate personal data quietly and rarely appear in the inventory that says where customer data lives. Establish which third parties hold your customers’ details, what fields, and for how long. Data deleted on schedule cannot be leaked.
Where integrations need credentials, scope them to the minimum function and keep them server side. A key permitting bulk export should never be reachable from a browser, and most frontend integrations do not need one.
Finally, settle your extortion position in advance at board level: who decides, what the regulatory obligations are, and what you would tell customers. MAG’s refusal looked clean because the operational stakes were low. That clarity is far harder to reach at three in the morning with systems encrypted.
Key message: Attackers reportedly reached 8.8 million customer records using administrative keys visible in a website’s own JavaScript, and published 550 GB after the ransom was refused. No perimeter had to be broken because the credential was already public. Audit your frontend for exposed secrets, map which third parties hold your customer data, and settle your extortion position before you need it.
