Manchester Airport Hacked: What US Businesses Should Know

On August 27, 2026, Manchester Airport was hacked, and the fallout did not stop at Manchester. Manchester Airports Group (MAG), the company that owns and runs Manchester Airport along with London Stansted and East Midlands has confirmed that an unauthorized third party had accessed customer data connected to all three sites. Within days, an extortion group calling itself FulcrumSec claimed responsibility and said it had pulled out dozens of gigabytes of traveler data, and eventually published the stolen dataset after MAG refused to pay.

It would be easy for a US reader to file this under "UK aviation story" and move on. That would be a mistake. The way FulcrumSec says it got in has nothing to do with airports specifically. It is one of the most common, most preventable errors on the modern web, and it is sitting on more American company websites than most executives would like to admit. Here is what actually happened, why it ended up breaching three UK airports at once, and what a US business can do this month to avoid becoming the next case study.

What Happened When Manchester Airport Was Hacked

MAG said in a statement that it had "been subject to a cyber security incident by an unauthorised third party" who obtained customer data tied to car park, lounge, and Fast Track bookings, along with in-airport WiFi sign-ups. According to reporting from the BBC and The Guardian, the compromised systems served customers at all three airports MAG owns, not just Manchester.

MAG has been clear about what the incident did not touch. No bank details or payment card information were stored on the affected systems, and flights, passenger safety, and day-to-day airport operations were never disrupted. The company also confirmed it had received a ransom demand and chose not to pay it, saying it had immediately contained the risk and was working with specialist advisers and the relevant authorities. That response is fairly standard for a breach of this size. The number attached to it is not: roughly 8.7 million customer records.

The Vulnerability Behind Breaching Three UK Airports at Once

The reason a single flaw ended up breaching three UK airports rather than just one comes down to how MAG's digital operations are built. Manchester, Stansted, and East Midlands share common backend systems for handling bookings, WiFi registrations, and customer communications across all three sites. Once that shared system was compromised, the exposure was not one airport's worth of customers. It was MAG's entire customer base at once.

Centralizing operations across multiple locations is normal, even sensible, for cost and consistency. It also means a single exposed credential can carry the weight of three separate customer bases instead of one. That is a pattern worth remembering if your own business runs multiple brands, locations, or product lines through a shared backend.

FulcrumSec's Claim: 86 GB of Data and a Mistake Almost Any Company Could Make

Three days after MAG's disclosure, the extortion group FulcrumSec told BleepingComputer it was behind the attack and had exfiltrated approximately 86 GB of data. FulcrumSec does not encrypt systems the way a traditional ransomware crew would. Researchers who track the group describe its playbook as "steal and squeeze," meaning it skips the disruption entirely and goes straight to threatening publication unless it gets paid. The group has reportedly claimed close to two dozen victims across roughly a dozen countries since late 2025, including a $25 million extortion attempt against Novo Nordisk earlier this year that the drugmaker also refused to pay.

What makes the MAG incident worth your attention is not FulcrumSec's résumé. It is the method. FulcrumSec says it found live API credentials for Iterable, a customer engagement platform MAG uses for marketing and bookings, sitting inside the JavaScript code that MAG's own website sends to every visitor's browser. Anyone who opened developer tools and looked at the page source could see the key. No password guessing, no phishing email, no exploit chain required, just a credential that was never supposed to be public, sitting in plain text where the public could read it.

This is not a rare mistake. GitGuardian's most recent research counted roughly 28.65 million new hardcoded secrets exposed in public GitHub repositories in 2025 alone, up 34 percent from the year before, and that figure does not include private repos, staging environments, or the kind of client-side JavaScript FulcrumSec says it used here. If you have ever pulled up a website's page source out of curiosity, you already understand how much a browser can see.

What Was Actually Taken (and What Wasn't)

According to MAG's disclosure and the dataset FulcrumSec later published, which was reviewed by the breach-notification service Have I Been Pwned, the exposed information included:

• Email addresses, for the large majority of the roughly 8.7 million affected customers
• Phone numbers, postcodes, and vehicle registration plates for a smaller subset
• Names, IP addresses, device and browser details, and approximate geolocation
• Purchase histories tied to parking, lounge access, and Fast Track bookings
• Around 200,000 records connected to upcoming travel through the rest of 2026, according to FulcrumSec's own claims

What was not exposed matters just as much. MAG has consistently said that no payment card numbers or banking details were on the affected systems, and that passenger safety and flight operations were never at risk. That distinction is genuinely important. It just does not make the rest of the data harmless. Email addresses paired with real names, phone numbers, and upcoming travel dates are exactly the ingredients used in convincing phishing and impersonation scams, the kind that reference a real booking to sound legitimate.

Why a UK Airport Story Should Matter to a US Business

Three reasons say this is not just a UK problem.

US aviation is under the same kind of pressure.

The TSA issued an emergency cybersecurity amendment for TSA-regulated airport and aircraft operators requiring network segmentation, continuous monitoring, and faster patching, and a July 2026 report from the Government Accountability Office found that the FAA and TSA still have overlapping, unclear roles on aviation cybersecurity along with gaps in how the FAA tracks its own security spending. CISA's Binding Operational Directive 26-04, issued in June 2026, pushes federal agencies toward the same exposure-based prioritization that would have flagged a publicly readable API key immediately. Regulators on both sides of the Atlantic are converging on the same idea: assume attackers will find whatever is exposed, and fix it before they do.

The vulnerability itself has nothing to do with aviation.

An API key hardcoded into client-side JavaScript is a web development mistake, and it shows up in ecommerce platforms, healthcare portals, SaaS dashboards, and marketing sites across every US industry. If your business connects to a third-party marketing platform, CRM, booking system, or analytics tool from code that runs in a customer's browser, you are one misconfigured integration away from the same story.

The price tag is real, and it is climbing.

IBM's 2026 Cost of a Data Breach Report, released in July, put the global average cost of a breach at a record $4.99 million, up 12 percent year over year, with the US average at $11.5 million, more than double the global figure. Breaches involving a compromised third-party platform, which is exactly the pattern MAG is describing, took the longest of any category to identify and contain and added roughly $227,000 to the average bill. We've covered the state-by-state patchwork of US breach notification law in more detail in our roundup of top US cybersecurity firms, but the short version is this: there is still no single federal standard, and the clock starts the moment you find out, not the moment you're ready.

The Real Lesson: How to Keep Your Business Off This List

Strip away the airports and the extortion drama, and the MAG incident is a case study in a handful of very fixable gaps.

A credential that should never have shipped to the browser did. This is exactly what a manual penetration test is built to catch. A scanner might flag an exposed endpoint, but a tester manually reviewing a site's client-side code, the way our penetration testing team does on every web and API engagement, is looking specifically for hardcoded secrets, overly permissive API keys, and the kind of quiet exposure that never trips an alarm until an attacker finds it first.

Nobody appears to have been checking for it continuously. Secrets rarely appear all at once. They accumulate as developers ship features, connect new tools, and copy code between environments. Catching them requires ongoing, prioritized visibility, which is what our vulnerability assessment work is built around, ideally paired with secret-scanning baked directly into the CI/CD pipeline before code ever reaches production. That pipeline-level check is the core of what we do in our DevSecOps engagements.

The exposed key reportedly had far more access than a marketing integration needed. A well-scoped API key should only be able to do what the integration actually requires, nothing more. That is an identity and access management problem as much as a code problem, which is why our identity and access management reviews look specifically at how third-party integrations are provisioned, not just how employees log in.

The data lived on a third-party marketing platform, not MAG's own infrastructure. Most businesses now route customer data through a half-dozen SaaS tools, and each one is part of your attack surface whether you configured it yourself or not. Reviewing how those platforms are set up and who can reach them is core cloud security work.

And once something like this happens, the response has to hold up to regulators, not just customers. MAG will be answering to UK data protection authorities under UK GDPR. A US company facing the equivalent would be managing a state-by-state notification process, possibly an SEC disclosure if it is publicly traded, and an insurer asking hard questions about what testing had been done beforehand. That is exactly the kind of audit-ready documentation our compliance consulting work is meant to have ready before you need it, not after.

A Quick Self-Check for Your Own Website

You do not need an incident to find out if you have the same exposure. Right now, with nothing more than a browser:

• Open your site's most-visited pages, right-click, and view the page source or use developer tools. Search for words like "key," "token," "secret," or the name of any marketing, analytics, or booking platform you use.
• Ask every vendor with a customer-facing widget or embedded script (chat tools, marketing platforms, booking systems, analytics) how their API keys are scoped, and whether those keys can reach customer data beyond what the integration actually needs.
• Check whether your development team runs secret-scanning inside the CI/CD pipeline, not just at the point of deployment.
• Rotate any API keys that have been in place for more than a year, especially ones tied to third-party marketing or engagement platforms.
• Confirm your incident response plan actually names who calls which regulator, in which state, within how many hours. A plan that only gets read after the fact is not a plan.

If any of that turned up something you did not expect, or if you genuinely are not sure, that uncertainty is the finding.

Get Ahead of It Before Someone Else Finds It First

MAG will spend the next several months on customer notifications, regulator conversations, and rebuilding trust with 8.7 million people, over a credential that a five-minute look at their own website's source code could have caught. That is the real story here. Not the airports, not FulcrumSec's track record, but how small the gap was between a normal Tuesday and a breach affecting millions of people.

If you want to know whether your own site, app, or customer platform carries the same kind of exposure, Pluto Security offers a free security assessment with a senior engineer, not an automated scan with your name printed on the cover page. It is a faster and considerably less expensive way to find out than reading about it in a breach notification letter.