- The Mess: Attackers breached Manchester Airports Group and obtained customer data tied to three UK airports, with the attackers later claiming exposed API credentials were the way in.
- The Damage: Around 8.7 million records were affected, including email addresses, phone numbers, vehicle registrations and postcodes.
- The Fix: Stop shipping privileged API credentials to browsers, rotate exposed secrets immediately, and treat client-side JavaScript as public code.
Manchester Airports Group runs airports.
It also runs APIs.
One of those boundaries turned out to be much more interesting to attackers.
MAG confirmed that an unauthorized party obtained customer information connected with Manchester Airport, London Stansted and East Midlands Airport. The affected data relates to parking, lounge and Fast Track bookings and airport Wi-Fi registrations.
The company says the compromised system did not contain bank or payment information and that aviation security and passenger safety were not affected.
The number is still ugly: about 8.7 million people.
The API Became the Target
The most interesting technical claim came from FulcrumSec.
The extortion group claimed it obtained airport-specific Iterable API credentials exposed in client-side JavaScript. Security reporting repeated the claim after the incident became public.
If those credentials were genuinely usable from outside the intended application, the architecture had a basic problem:
the secret was already available to anyone capable of inspecting the web application.
Client-side JavaScript is not a vault.
Anything delivered to a browser should be considered obtainable by the user — and therefore by an attacker.
Obfuscation does not change that.
Minification does not change that.
Putting the credential into a complicated JavaScript bundle does not change that.
8.7 Million Records
MAG says the stolen information includes:
- email addresses;
- phone numbers;
- vehicle registration numbers;
- postcodes.
The data came from parking, lounge, Fast Track and airport Wi-Fi systems. MAG says payment and banking information was not held in the affected system.
That is still enough to build highly convincing phishing campaigns.
An attacker does not need your credit-card number if they already know:
your email + phone + postcode + vehicle + airport relationship.
A message pretending to be about airport parking or a recent booking suddenly looks much more believable.
The Third-Party Database Matters
MAG said the affected data was stored in a database hosted by a third party. SecurityWeek reported that FulcrumSec claimed to have stolen roughly 86 GB of data.
That creates another security question.
The attack surface was not necessarily just MAG’s own infrastructure.
It included the software integration connecting MAG’s services with external platforms.
This is how modern breaches often work.
The attacker does not need to compromise the entire company.
They find one integration with enough authority to extract useful data.
Why Client-Side Secrets Keep Failing
Developers sometimes put API keys into frontend code because the API itself appears harmless.
That can work only when the credential is intentionally public and the backend independently enforces authorization.
A secret capable of retrieving customer information is different.
Once it reaches a browser, the security model collapses.
An attacker can inspect:
- JavaScript bundles;
- source maps;
- browser network requests;
- local storage;
- configuration objects;
- API calls;
- embedded environment variables.
The browser is hostile territory.
Treating it otherwise is asking for an incident.
The Leak Gets Worse After the Breach
FulcrumSec reportedly attempted to extort MAG and later published or offered the stolen information after the company refused to pay.
That changes the economics of the incident.
Once the dataset escapes, MAG no longer controls who has a copy.
The original attacker may not even be the biggest problem anymore.
Other criminals can download the material, enrich it with other datasets and turn it into phishing campaigns.
A database containing millions of airport customers is particularly useful for impersonating travel services.
What Developers Should Check
If your application uses a browser-facing API, inspect every credential embedded in frontend assets.
Ask:
- Is this key actually supposed to be public?
- Can it retrieve customer data?
- Can it enumerate records?
- Does the backend enforce authorization independently?
- Can the key be restricted by origin, scope or endpoint?
- Does it expire?
- Can suspicious bulk extraction be detected?
Then search historical JavaScript bundles and Git repositories.
Removing a secret from today’s build does not invalidate yesterday’s credential.
Rotate it.
Bugstoday Opinion
The scary part is not the number alone.
It is how familiar the failure mode looks.
A secret appears in frontend code because somebody needs it to make an API call. Months later, somebody else notices that the browser was never a trustworthy place to keep secrets.
Then millions of records leave through an interface that was supposed to make the application work.
MAG says passenger safety was unaffected.
Good.
But 8.7 million customer records still walked out of an airport operator’s systems.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
Manchester Airports Group — Data Security Incident Update & FAQs
SecurityWeek — FulcrumSec Claims Manchester Airports Group Data Breach
The Guardian — Manchester Airports Group Cyberattack
TechRadar Pro — Manchester Airports Group Data Leak
