Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Iterable

  • FulcrumSec’s Manchester Airports sample shows itineraries and payment amounts that MAG’s own statement does not list as taken

    FulcrumSec’s Manchester Airports sample shows itineraries and payment amounts that MAG’s own statement does not list as taken

    A group calling itself FulcrumSec claims 86 GB from Manchester Airports Group and published a sample of upcoming flight itineraries and payment amounts — categories of data that MAG’s own August 27 statement does not list among what was taken.

    What happened

    Severity Daily covered the MAG incident on Saturday, August 29, when the company had confirmed a breach of a third-party-hosted database and reporting put the figure at 8.7 million customers. What changed on Sunday, August 30, 2026 is that an extortion group put a volume, a sample, and a claimed access path behind it — and the sample describes data MAG has not said was taken.

    MAG’s published statement is dated August 27, 2026 at 11:48 Europe/London and has not been updated since. In it, the company says: “Manchester Airports group has been subject to a cyber security incident by an unauthorised third party. A quantity of customer data has been obtained that relates to car park, lounge and Fast Track bookings and in-airport WIFI sign-ups at Manchester, Stansted and East Midlands airports.” On what the data contains, it is specific: “Neither MAG nor the system accessed hold customers’ bank or payment details. The data that has been accessed includes customers’ email addresses, phone numbers, vehicle registrations and postcodes.” The statement adds that “At no point has passenger safety or aviation security been compromised” and that “The incident has not resulted in any operational disruption.”

    That is a list of four field types: email address, phone number, vehicle registration, postcode.

    FulcrumSec’s claim, reported by BleepingComputer on August 30, describes something wider. The group claims roughly 86 GB in total, including a 21.5 GB Manchester customer export of consolidated profiles and close to 200,000 records that it says carry upcoming travel dates and times along with booking information. BleepingComputer reported that it checked one traveler’s record against that person and found it accurately listed previous Fast Track purchases, booking and scheduled-arrival times, the terminal used, amounts paid, purchase references, and total spending.

    Two of those items sit outside MAG’s four fields, and one of them sits against MAG’s explicit denial. Scheduled arrival times and terminal for an upcoming trip are itinerary data, not contact data. Amounts paid, purchase references, and total spending are transaction records. MAG’s statement says neither MAG nor the accessed system holds “bank or payment details,” which is a narrower claim than it may read as: a purchase amount and a purchase reference are not a card number, and a company can be truthful about the second while the first was still taken. Whether that is the explanation here, or whether the description is simply incomplete, is not something an outside party can settle.

    FulcrumSec also claims an access path: airport-specific Iterable API credentials exposed in client-side JavaScript. Iterable is a marketing and customer-engagement platform, which is consistent with the third-party-hosted database MAG’s incident has been described around. It is an attacker claim. Neither MAG nor Iterable has confirmed it, and there is no published evidence for it beyond the group’s assertion.

    MAG has not issued a new statement. Asked about the claims before BleepingComputer published, a spokesperson declined to address them specifically and said: “MAG is confident that we have taken effective measures to protect our customers and we have contacted all those affected.” That is the only new comment from the company, it was given to a publication rather than posted, and the company’s own newsroom still carries only the August 27 text.

    Why it matters

    The gap between a victim’s field list and a leak sample is one of the most consequential things to get right in breach coverage, and it is routinely gotten wrong in both directions. Outlets take the attacker’s inventory at face value, or they take the company’s list as the ceiling. Neither is safe. A company writes its first statement within days, from a partial forensic picture, describing the system it believes was reached. An extortion group writes its listing to maximize pressure and has every reason to inflate. The useful reporting is the comparison itself, held open.

    What makes this particular gap worth acting on is who is exposed by it. Contact details plus a vehicle registration and a postcode enable phishing, and that is bad. Contact details plus a confirmed upcoming flight — date, time, terminal, what the traveler already paid for — enable something meaningfully worse. A caller who knows a person is flying from Terminal 2 on Thursday morning, knows they bought Fast Track, and knows what they paid for it, does not need to be persuasive. That is a pretext that works on people who would hang up on anything else, and its shelf life is exactly as long as the trip. It also has a physical dimension nobody enjoys thinking about: a vehicle registration, a home postcode, and a departure date together say which house is empty and which car is in the long-stay car park.

    The disclosure asymmetry matters too. Someone who received MAG’s notification read that their email address, phone number, vehicle registration, and postcode were involved, and would reasonably calibrate their guard to that. If itinerary and transaction data were also taken, that person is under-warned in a way that a corrected statement would fix and a spokesperson’s line to a reporter will not. MAG says it has “contacted all those affected”; contacting people is a different question from telling them what was taken.

    Finally, the claimed access path, if it holds up, is a boring failure worth naming. API credentials for a customer-engagement platform sitting in client-side JavaScript is a mistake anyone can check for in an afternoon: it is visible in view-source, it survives every network control, and it grants whatever the platform grants. Marketing platforms accumulate more customer data than almost anyone inside a company tracks, precisely because their job is to hold everything needed to personalize a message. The keys to them are routinely treated as less sensitive than the data behind them.

    What to do

    If you are a MAG customer, treat an upcoming trip as known to somebody else. Expect calls, texts, and emails referencing real booking details, and do not treat accurate details as proof of legitimacy — that is the whole point of this data. Arrange anything that needs arranging through the airport’s or airline’s own app or published number.

    For security teams, the transferable check is the one FulcrumSec claims to have used. Audit front-end bundles for credentials to any customer-engagement, analytics, or marketing platform: search deployed JavaScript for API key patterns rather than searching your source repositories, since the two diverge. Confirm that every such platform’s keys are scoped to the minimum operation the browser actually needs, and that anything capable of exporting records is server-side only.

    Inventory which third-party platforms hold customer records on your behalf and what fields each one has. Most organizations discover during an incident that the marketing stack holds more than the CRM. Knowing the field list before you have to write a public statement is what keeps that statement from needing correction.

    Sourcing note

    MAG’s statement is quoted verbatim from MAG’s own published statement page, dated August 27, 2026 at 11:48 Europe/London; that page carries no update. British spellings and the company’s own date format are preserved inside the quotation marks and not corrected.

    The FulcrumSec figures — 86 GB, a 21.5 GB export, nearly 200,000 records — and the Iterable access path are attacker claims, reported by BleepingComputer on August 30, 2026. Severity Daily has not seen the listing or any sample, and has not independently verified any of it. The record validation described above is BleepingComputer’s own, on a single traveler’s data, reported by that outlet; it is not this publication’s verification and it does not establish the scale of the rest.

    The 8.7 million figure comes from reporting on the notification rather than from MAG’s published statement, which gives no number. MAG’s new comment was given to BleepingComputer and has not been published by the company. Iterable has published nothing. No regulator finding is available; the Information Commissioner’s Office has been informed but has not issued a determination.

    Unresolved and stated as such: whether itinerary and transaction data were in scope, whether MAG’s field list was incomplete or the attacker’s sample is misrepresented, whether the Iterable credential claim is accurate, and the true record count. No attribution beyond the group’s self-identification is asserted here.