Most breach headlines imply a fight: an attacker against a defense. This one, if the attacker's own account holds, was not a fight. It was a key sitting in public view, in a file every visitor's browser already downloaded, for however long nobody checked.
The Week's Signal
On August 27, 2026, Manchester Airports Group told customers of its Manchester, London Stansted, and East Midlands airports that an unauthorized third party had obtained data tied to car park bookings, lounge and Fast Track purchases, and in-airport Wi-Fi sign-ups. The company's own account is narrow and specific: email addresses, phone numbers, vehicle registrations, and postcodes. No payment card or bank details. No stated customer count. No named cause.
Three days later, on August 30, the extortion group FulcrumSec claimed responsibility and offered a very different picture of scale: 8,672,291 customer profiles, 1.2 billion marketing events, 2.5 million purchase records, 461,000 SMS messages, 108,000 vehicle registration plates, and 191,000 records tied to upcoming 2026 travel, all pulled from a customer-engagement platform called Iterable using, in the group's own words, “admin keys in the frontend JavaScript of each of its three airports' websites” that “any of the millions of visitors to the site could have right-clicked 'inspect' and seen... just sitting there, plain as day.” MAG has not confirmed that account. Have I Been Pwned loaded roughly 8.8 million email addresses and phone numbers from the leaked dataset into its own database on September 2, after FulcrumSec published the data on its leak site once MAG declined to pay.
Two organizations describing the same event, three days apart, and only one of them has named a mechanism.
The Incident Ledger
What MAG has confirmed. MAG's own incident FAQ, dated August 27, 2026, states that data was accessed from systems supporting car park, lounge, and Fast Track bookings and in-airport Wi-Fi registration across its three airports. It confirms the affected data types (email, phone, vehicle registration, postcode) and is explicit that bank and payment details were not compromised. It does not name a cause, a vendor, or a customer count, stating only that the company has “informed and are working with the relevant authorities” and has engaged unnamed “specialist cyber security experts.” According to The Register, MAG temporarily pulled access to its Manage My Booking service following the incident, and the ransom demand the group made was, per the same reporting, considerably lower than typical for a claimed dataset of this size. That is a detail MAG's own FAQ does not address, since it says nothing at all about a ransom.
What FulcrumSec claims. The technical account of how this happened comes entirely from the attacker. FulcrumSec says it found Iterable administrator API keys hardcoded into the client-side JavaScript served on the public root domains of all three MAG airport websites, code that ships to every visitor's browser and is visible to anyone who opens developer tools. Iterable is a customer-engagement platform used for marketing and transactional messaging; an admin key for it can typically read and export the audience data the platform holds. FulcrumSec says it used that key to pull the full customer dataset directly from Iterable's API: no phishing, no malware, no password guessing against MAG's own network. SecurityWeek's own reporting is blunt about the evidentiary status of this claim: “SecurityWeek hasn't independently verified it, so the claim remains unproven.” MAG has not addressed the Iterable claim, the 86 GB (roughly 640 GB uncompressed) figure, or the specific record breakdown in any public statement as of this writing.
What's independently corroborated. Two things sit outside either party's own telling. First, Have I Been Pwned's independent load of roughly 8.8 million email addresses and phone numbers from the published dataset is evidence that a real, large dataset matching MAG's customer base exists and was actually distributed; that part is no longer just a claim, whatever the entry method turns out to have been. Second, according to The Register, the UK's Information Commissioner's Office asked MAG to withhold the ransom note, the specific demand, and the extortion group's name from public disclosure, a detail that appears only in that outlet's reporting, not in MAG's own FAQ or in any ICO statement traced independently for this issue.
Why This One Matters
Most coverage of this incident reads it as a hack: an adversary broke into an airport operator's systems. If FulcrumSec's own account is accurate, that is not what happened. Nobody broke in. A working credential for a third-party platform was already sitting in a public file, shipped to every visitor's browser, discoverable with a right-click.
That distinction matters because it changes where the failure sits. A break-in implies a perimeter that was breached. A hardcoded key in client-side code is not a perimeter failure. It is a code-review and secrets-management failure, and it can sit undetected for an indeterminate stretch of time because the file that carries it is not on anyone's list of “internal systems” to monitor. It is marketing website code. It ships to the public by design. The question a security team almost never asks about that class of asset is whether it is also quietly shipping a working credential to every visitor along with the page.
The Mechanism
FulcrumSec's account of how the data left MAG's control, treated here as a claimed sequence rather than a confirmed one, runs as follows. The group examined the publicly served JavaScript on the root domains of MAG's three airport websites, the same code any visitor's browser loads to render the page (T1594 — Search Victim-Owned Websites). Inside that code sat hardcoded Iterable administrator API keys, stored in a client-side file rather than a server-side secret manager (T1552 — Unsecured Credentials). Because the key was live and scoped with administrative reach, FulcrumSec says it used it directly as authentication material against Iterable's own API, without needing to compromise any MAG-owned account or system (T1550.001 — Use Alternate Authentication Material: Application Access Token). From there, the claimed path is a bulk pull of customer records, purchase history, SMS logs, and marketing-event data directly out of Iterable, a SaaS platform MAG does not host itself (T1213.006 — Data from Information Repositories: SaaS Repositories). The dataset was then moved to attacker-controlled infrastructure and, after MAG's refusal to pay, published on FulcrumSec's leak site (T1567 — Exfiltration Over Web Service). Both the ransom demand and its later publication after refusal are documented: the demand by The Register's reporting, the publication independently by Have I Been Pwned's own ingestion of the leaked dataset (T1657 — Financial Theft).
Analytical ATT&CK Mapping
T1078.004 — Valid Accounts: Cloud Accounts was considered and not used above. FulcrumSec's own account describes using a found API key directly against Iterable's API, not signing in to a MAG-owned or Iterable-owned user account. The more precise fit is T1550.001, application access token material, not a valid account logon.
The Prevention Gap
The control most relevant here is not one most security programs test at all: whether the client-side code an organization ships to the public internet, across every domain and microsite it operates, contains a working credential for anything. Vendor risk reviews check contracts and data processing agreements. Penetration tests usually scope to the production application and its authenticated paths, not a systematic read of every JavaScript bundle a browser downloads on page load. A secrets scanner run against an internal source repository would not have seen this, if FulcrumSec's account is right, because the exposure was never in a repository anyone was scanning. It was already in the file being served to the public.
That is a testable claim about a specific environment, not a policy statement. An organization can state that its vendor credentials are properly scoped and stored. Whether a live admin key for a third-party platform is actually sitting inside a public-facing asset, discoverable by anyone with a browser's developer tools, is a different question, and for three months, or three years, nobody may be asking it, because the asset in question does not look like the kind of thing an internal security review usually inventories.
What To Do Before The Next One
Three things worth doing before the next public JavaScript file gets read closely by someone who isn't a customer:
First, inventory every credential (API key, admin token, or client ID) currently shipping in client-side code across every domain, subdomain, and microsite the organization operates, not just the flagship application. Marketing sites, campaign microsites, and vendor-embedded widgets are usually outside the scope of an application security program precisely because nobody built them internally.
Second, scope every third-party SaaS credential to what it actually needs. An admin key for a marketing platform that only needs to trigger campaign sends has no operational reason to be able to export a full customer database; if FulcrumSec's account is accurate, that mismatch between granted and needed scope is most of the story here.
Third, treat an organization's own public web surface, across every domain and microsite it owns, as attacker reconnaissance surface and keep continuous, comprehensive visibility over it, not an annual audit cycle. digiDations' HELIOS™ External Attack Surface Management platform is built for this specific gap: continuous global discovery of an organization's full internet-facing footprint (domains, subdomains, certificates, and web fingerprints included) with minute-level change detection when something in that footprint is added or altered. A marketing microsite three airports operate is exactly the kind of asset that a security team without full, current external inventory has no visibility into at all, let alone what's shipping inside it.