Airport WiFi sign-ups turn into a national data problem as 8.7 million customer records are accessed

Share

What happened

Manchester Airports Group, the owner of Manchester, East Midlands and London Stansted airports, has confirmed a cyber security incident in which criminal hackers accessed the data of about 8.7 million customers.

According to BBC News, the group said contact details, vehicle registrations and postcodes were obtained at the weekend. The group became aware of the incident on the Tuesday, stopped further access, notified affected customers and informed the relevant authorities. It stated that passenger safety and aviation security were never compromised, and that the system involved did not hold bank or payment details.

The majority of the accessed records were customer email addresses collected when passengers signed up to free WiFi inside the terminals. The more detailed records, including vehicle registrations, came from customers who booked car parking, lounge access or fast-track security.

Update: no hacking was required

Independent research published by security researcher Scott Helme has now established how the data most likely left the group, and it changes how this incident should be read.

The group calling itself FulcrumSec said it did not hack anything. It said it read an API key out of the websites' own JavaScript. Helme tested that claim and found it stood up:

• Three separate keys for the Iterable marketing platform, one each for Manchester, Stansted and East Midlands, were published inside the JavaScript bundles served to every visitor of the three airport websites.
• Internet Archive captures of those bundles show the keys appearing in June and July 2022 and remaining unchanged in every capture until August 2026. They were never rotated in more than four years.
• The Stansted key was emptied on 25 August 2026, at least two days before the group went public. Manchester's was emptied on 27 August 2026.
• The keys were server-side credentials. Iterable's own documentation carries an explicit warning never to embed a server-side key in client-side code, and Iterable issues restricted browser keys for exactly this purpose.

A server-side key of that class reaches almost the whole platform API, including a single request that exports the entire user table, and the endpoints that delete customers, delete lists and rewrite profiles in bulk. FulcrumSec described roughly 86GB compressed, extracting to around 640GB, including about 200,000 records covering travel booked for 2026 with dates, times and booking references tied to names.

The purpose the key served was attribution. A small piece of code recorded a page view against a marketing email campaign, and wrote a value into browser storage that no other code on the site ever read.

Why the numbers are so large

Nothing about this incident required an attacker to reach a flight system, a baggage system or a payment platform. The exposure came from the ordinary commercial edge of an airport: the marketing database that sits behind a WiFi splash page, and the booking systems for parking and lounges.

That is exactly where volume accumulates. A single terminal can capture tens of thousands of email addresses in a week, and it keeps them. Three airports operating for years produce a dataset of national scale, held in a system that is permanently online because it has to serve a captive portal and a booking website.

The valuable fields were not typed into the browser. Parking history, vehicle registrations and forward travel were loaded into the marketing platform by a server-side synchronisation from the booking estate. The exposure was therefore not a leak of what the website handled. It was a leak of everything the marketing platform held.

The result is a familiar shape. A low-sensitivity system holds a very high-volume dataset, stays connected at all times, and retains that data long after the commercial reason for holding it has expired.

Why email addresses and number plates matter

It is tempting to treat this as a minor breach because no payment data was involved. That underestimates what the attackers now hold.

• An email address linked to a named airport tells a criminal that the person travels, and gives a credible pretext for a phishing message about a booking, a parking charge or a refund.
• A vehicle registration linked to a postcode and a parking booking is close to an address, a movement record and a period of absence from home.
• A forward travel record naming a person, a vehicle and a departure date is a different class of exposure again, because it describes an empty home on a known date.
• Combined, the set supports convincing fraud at scale, which is why customers are being urged to be cautious about unexpected emails, messages and calls, and to avoid opening attachments from unknown contacts.

Under UK data protection law, a large volume of contact data is still personal data, and the obligation to hold it securely and only for as long as necessary does not soften because the fields look harmless.

The Firevault view

The technical failure here is secondary. The structural failure is retention.

Every one of those records was reachable because it was sitting in a connected system that no longer needed to hold it. A WiFi sign-up from three years ago does not need to be online. A completed parking booking from last season does not need to be online. Yet in most organisations there is no defined destination for data that must be kept but must not remain exposed, so it stays in the live estate by default.

"An airport does not need eight point seven million email addresses within reach of the internet," said Mark Fermor of Firevault. "It needs a small amount of that data live, and the rest held somewhere an attacker cannot route to. The moment data has no operational reason to be connected, leaving it connected is a decision, not an accident."

The research makes that point sharper rather than softer. A credential published in a public file for four years is a control failure, and it is the kind of control failure no firewall, no penetration test scope and no server log would have caught, because the traffic never touched the group's own infrastructure.

"Every organisation should assume that a key which can be read will be read," said Mark Fermor. "The question that follows is the only one that matters: when someone holds that key, how much of your data can it reach? If the answer is all of it, the problem is not the key. It is that everything was still connected."

This is what Offline Secure Storage® is for. Records that must be retained for commercial, legal or analytical reasons are moved to storage that is physically disconnected, so the volume of data an intruder can reach is a fraction of the volume the organisation holds. The service stays online. The archive does not.

Two controls follow from that principle:

1. Reduce the connected footprint. Keep only the records the live service needs, and move historic marketing, booking and customer records into Offline Secure Storage, where they remain retrievable but unreachable.
2. Contain the path, not only the data. Where operational and customer-facing systems share networks, use a designed containment control so a compromise in the commercial estate cannot be widened. Our containment blueprint sets out how that separation is enforced physically rather than by configuration alone.

Airports are critical national infrastructure with a very large consumer business attached to them. The consumer business is where the record counts live, and it is usually the least protected part of the estate. That is the gap worth closing.

What organisations should do now

• Establish how many customer records are held, and how many of them the live service actually requires.
• Set a retention period for WiFi, booking and marketing data, and enforce it.
• Move retained records that are not needed live into physically disconnected storage.
• Audit what your own public JavaScript contains, and confirm that every credential it carries is scoped to the handful of actions a browser needs.
• Rotate marketing and analytics platform keys on a schedule, and check what each key can reach rather than what it is used for.
• Test recovery from that storage, so disconnection never becomes an obstacle during an incident.
• Assume that contact data alone is enough to enable fraud, and warn customers accordingly.

If you are unsure which of your datasets should be disconnected, the OSS Concierge works through the data, the operating model and the architecture that fits.

Sources

• BBC News, "Hackers steal data from millions of airport customers": https://www.bbc.co.uk/news/articles/c7v4353rry7o
• Scott Helme, "No hacking required: Manchester Airports Group data breach": https://scotthelme.co.uk/no-hacking-required-manchester-airports-group-data-breach/
• Statement from Manchester Airports Group, as reported by BBC News

How Firevault would handle this

Access decided by you, not assumed by the network

Control by Firevault removes standing pathways and replaces them with connection windows you approve, so stolen credentials and compromised suppliers have nothing standing to abuse.