The Challenge
Manchester Airports Group (MAG) experienced a massive data breach when attackers exfiltrated 550 gigabytes of customer data from a third-party hosted database. This breach exposed 8.8 million email addresses and phone numbers, along with booking records, SMS messages, and vehicle registration plates. The stolen data included names, IP addresses, browser details, and purchase histories from services across Manchester, London Stansted, and East Midlands airports.
The vulnerability was admin keys exposed in the frontend JavaScript of each airport's domain. The extortion gang, FulcrumSec, accessed MAG's systems using credentials that any visitor could extract by viewing the page source.
The Environment
MAG's distributed data architecture meant customer booking data resided in a third-party database, while web applications ran across three airport domains. This setup created multiple points where secrets could leak.
The operational reality involved millions of transactions through web portals, mobile apps, and on-site Wi-Fi systems, each requiring authentication to backend services. Embedding authentication credentials directly in client-side code was a critical error, bypassing secure backend proxies.
When FulcrumSec issued a ransom demand, MAG refused to pay, leading to the public release of the stolen data.
The Approach Taken
MAG followed standard breach protocols by publicly disclosing the incident, notifying affected individuals, and confirming airport operations were unaffected. They acknowledged the third-party hosting arrangement but didn't prevent the initial exposure. Admin keys were accessible to anyone who knew where to look. No secrets management system protected them, and no code review or automated scanning flagged the credentials in client-side bundles.
The third-party hosting arrangement created a blind spot. MAG owned customer relationships and booking applications, but the database was elsewhere. This split responsibility requires explicit security controls at the handoff point, especially in application authentication to the data layer.
Results and Metrics
The breach impacted 8.8 million individuals. HaveIBeenPwned verified the leaked dataset, confirming the scope FulcrumSec claimed. The data included not just contact information but behavioral patterns, revealing travel habits and services used.
For MAG, the operational impact extended beyond disclosure. Every affected customer now has a permanent record in breach notification databases. The vehicle registration plates pose ongoing security concerns, and the SMS messages and booking details could be exploited for social engineering or security threats.
Refusing to pay the ransom meant accepting that the data would become public. FulcrumSec published the full dataset, making it available for fraud, phishing campaigns, or targeted attacks.
What They Would Do Differently
The frontend JavaScript exposure showed a misunderstanding of the browser threat model. Client-side code is public. Anything shipped to the browser is available to the world.
A secure architecture would route all database requests through a backend API that handles authentication server-side. The frontend would never see admin keys. It would send requests to an endpoint like /api/bookings, with authentication managed by a secrets management system like HashiCorp Vault or AWS Secrets Manager.
Code review processes should check for secrets in client-side bundles. Automated scanning tools can catch patterns resembling API keys or authentication tokens. These tools should run in CI/CD pipelines before code reaches production.
The third-party hosting arrangement needed clearer security boundaries. If MAG owned the application but not the database, the contract should specify how authentication works, who controls credentials, and how often they rotate. The hosting provider should alert MAG to unusual access patterns.
Static code analysis would have flagged the embedded credentials. Tools like git-secrets, TruffleHog, or commercial solutions from Snyk and GitGuardian scan repositories for exposed secrets. They can run as pre-commit hooks, catching problems before they reach version control.
Takeaways for Your Team
Treat client-side code as public infrastructure. Never embed credentials, API keys, or admin tokens in JavaScript, mobile apps, or any code running on user devices. Use short-lived tokens issued by your backend after proper authentication.
Implement secrets management early. Don't wait to adopt a secrets vault. Start with one from day one. Rotate credentials regularly and log every access to make it harder to leak secrets than to protect them.
Define security boundaries in third-party relationships. When splitting responsibility for a system, clearly define where security controls live. Who manages encryption keys? Who monitors access logs? These questions need answers in the contract, not during an incident.
Automate secret scanning in your pipeline. Add tools that check for exposed credentials before code merges. Make them mandatory. A pre-commit hook that catches an AWS key in a config file is invaluable.
Prepare for the ransom decision. MAG chose not to pay, accepting that the data would leak. This choice needs to be made consciously, with legal counsel, and with a plan for what happens next. Document your decision framework before you're under pressure.
The MAG breach wasn't sophisticated. It didn't require advanced exploits. It involved looking at publicly accessible JavaScript and copying credentials left there. Your team can prevent this scenario by reviewing what secrets your applications expose and moving them behind proper authentication boundaries.
