Afpersgroep FulcrumSec claimt de inbraak bij Manchester Airports Group en zegt tegen BleepingComputer ongeveer 86 GB aan klantgegevens te hebben buitgemaakt, binnengekomen via Iterable-API-sleutels die in de JavaScript van de luchthavensites stonden.
Die route is het deel dat je vandaag zelf kunt narekenen. Een API-sleutel in client-side JavaScript staat in de broncode van je eigen website, leesbaar voor iedereen die op bekijk-broncode klikt. Iterable is een platform voor e-mail- en klantcampagnes, precies het soort tooling dat bij Nederlandse bedrijven door marketing wordt aangezet en daarna zelden door iemand wordt nagelopen. Wie zo'n koppeling heeft draaien, kan binnen tien minuten zien welk type sleutel er in de pagina zit.
Wat bevestigd is en wat claim blijft
BleepingComputer kreeg samples van de groep en legde een van de records naast de bekende aankoopgeschiedenis van een reiziger. Dat record klopte tot in detail: eerdere Fast Track-aankopen, boekings- en geplande aankomsttijden, de gebruikte terminal, betaalde bedragen, aankoopreferenties en de totale besteding.
Wat de site niet zelfstandig kon vaststellen: de herkomst en de reikwijdte van de toegang, de totale omvang van de dataset, en de claim over bijna 200.000 records met reizen in de rest van 2026. Na de controle zegt de redactie al het aangeleverde materiaal te hebben gewist.
MAG wil de claims niet adresseren. Op vragen over de 86 GB, de blootgestelde sleutels en de toekomstige reisgegevens verwees een woordvoerder naar een verklaring dat het bedrijf effectieve maatregelen heeft genomen en iedereen heeft benaderd die geraakt is, ook klanten met een boeking die nog moet plaatsvinden. Op de eigen incidentpagina heeft MAG inmiddels Manage My Booking tijdelijk uitgezet en biedt het kosteloos annuleren of omboeken aan wie daarom vraagt. Er lag ook een losgeldeis, die het bedrijf naar verluidt heeft geweigerd.

De buit is gedetailleerder dan de vier velden
Toen het lek bij Manchester, Stansted en East Midlands naar buiten kwam en 8,7 miljoen klanten uit parkeer-, lounge- en wifisystemen bleek te raken, ging het om e-mailadressen, telefoonnummers, kentekens en postcodes.
De samples gaan verder. Daarin zitten aankoop- en boekingsreferenties, de gekozen luchthaven en het gekozen product, prijzen, kortingen, boekingsstatus, parkeerdata en -tijden, historische bestedingen, IP-adressen, een benadering van de locatie, apparaatinformatie en klantcontactgegevens. Betaalkaart- of bankgegevens kwam de redactie niet tegen. Een van de bestanden is een export van ongeveer 21,5 GB met samengevoegde Manchester-profielen, waarin klantidentificatie is gekoppeld aan historisch boekingsgedrag en marketingclassificaties.
Dat is het verschil tussen een adressenlijst en een dossier. Een Britse postcode dekt volgens het Office for National Statistics gemiddeld zo'n vijftien adressen, en soms maar een. Zet daar een kenteken, een terminal, een parkeerdatum en een betaald bedrag naast en een phishingbericht over een gewijzigde reservering hoeft niets meer te raden.
Wat Iterable zelf over die sleutels zegt
Iterable kent server-side en client-side sleutels, en waarschuwt in de eigen documentatie dat een server-side sleutel nooit in client-side code hoort, of dat nu JavaScript is of een mobiele app. Zulke sleutels hebben het hoogste niveau van lees- en schrijfrechten op een project.
Client-side sleutels kunnen minder, maar zijn niet onschuldig. Zonder verplichte JWT-authenticatie kan een aanvaller er API-aanroepen mee doen namens elke andere gebruiker in het project, zolang hij het e-mailadres kent of kan raden: berichten van anderen opvragen, het e-mailadres van een slachtoffer vervangen door zijn eigen adres, willekeurige gebruikers uitschrijven. Iterable zet JWT daarom standaard aan bij nieuwe client-side sleutels.
De controle die daaruit volgt is klein. Open de broncode en de netwerkverzoeken van je eigen pagina's, zoek naar de sleutels van je marketing-, chat- en reviewtooling, en kijk per sleutel welk type het is en of er JWT op staat. Dezelfde vraag geldt voor elk ander script dat je in de pagina laadt.
FulcrumSec steelt, het versleutelt niet
FulcrumSec is sinds 2025 actief en financieel gedreven. De groep gijzelt geen systemen maar steelt gevoelige bedrijfsdata en dreigt die te publiceren. Eerdere claims van de groep betreffen LexisNexis, Novo Nordisk, Global Schools Group en Avnet.
Blootgestelde toegang is in die zaken het terugkerende patroon. Bij Novo Nordisk kwam de groep binnen via twee publiek bereikbare sandbox- en ontwikkelsubdomeinen met Azure-registerinloggegevens en GitHub-tokens, analyseerde beveiligingsbedrijf Sysdig in juni, waarna de aanvallers ruim twee maanden binnen bleven. Bij LexisNexis was de ingang een kritiek lek dat maanden na publicatie nog niet gepatcht was.
FulcrumSec zegt de data en een technisch verslag van de inbraak te willen publiceren, maar overweegt de records over komende reizen weg te laten of onleesbaar te maken vanwege het risico op schade in de echte wereld. Daarin zit precies wat hier verschuift. Gestolen klantdata is allang geen adresboek meer maar een agenda: iemand weet welke terminal, welke datum, welk bedrag en welk kenteken. En als de claim over de sleutels klopt, lag de ingang niet achter een firewall of in een gephishte inbox, maar in een regel JavaScript die elke bezoeker van de site kon lezen.
Veelgestelde vragen
Sleutels waar ze horen
Bij elke koppeling die ik bouw blijft de sleutel op de server en krijgt de browser alleen wat hij mag zien. Ik denk mee over het ontwerp, realiseer de koppeling en automatiseer wat erachter hangt, self-hosted waar dat kan.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
