Manchester Airports Datenleck: 8,8 Mio. Reisende betroffen

Manchester Airports Datenleck: FulcrumSec veröffentlicht Daten von 8,8 Mio. Reisenden. Einstieg über API-Keys im JavaScript. Was Admins jetzt prüfen müssen.

Das Manchester Airports Datenleck ist seit dieser Woche öffentlich: Die Erpressergruppe FulcrumSec hat die Daten von rund 8,8 Millionen Reisenden ins Netz gestellt – nach eigenen Angaben, weil der britische Flughafenbetreiber Manchester Airports Group (MAG) das geforderte Lösegeld nicht gezahlt hat. MAG bestätigt eine Forderung, äußert sich aber nicht zur Zahlung. Der Weg hinein war so banal wie lehrreich: Nach Angaben der Angreifer lagen Admin-Schlüssel eines Marketing-Dienstes offen im JavaScript der Flughafen-Websites.

Was passiert ist

MAG betreibt die Flughäfen Manchester, London Stansted und East Midlands. Am 27. August 2026 bestätigte das Unternehmen einen Sicherheitsvorfall: Ein Unbefugter hatte Kundendaten aus Parkplatz-, Lounge- und Fast-Track-Buchungen sowie aus WLAN-Anmeldungen an den Flughäfen abgezogen. Betroffen sind laut MAG E-Mail-Adressen, Telefonnummern, Kfz-Kennzeichen und Postleitzahlen. Zahlungsdaten seien nicht gespeichert gewesen, der Flugbetrieb blieb unberührt.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Wenige Tage später reklamierte FulcrumSec den Angriff für sich und legte BleepingComputer Datenproben vor, die das Medium an einem echten Buchungsverlauf verifizieren konnte. Am 2. September tauchte der Datensatz auf der Leak-Seite der Gruppe auf; Have I Been Pwned nahm ihn noch am selben Tag auf, hat ihn ausgewertet und rund 8,8 Millionen E-Mail-Adressen samt Telefonnummern, Namen, IP-Adressen, Käufen und Kennzeichen aufgenommen. Die Angreifer selbst sprechen von 550 bis 640 GB unkomprimierten Daten (die Angaben gegenüber SecurityWeek und BleepingComputer weichen voneinander ab), darunter knapp 2,5 Millionen Buchungen und über 100.000 britische Kennzeichen. Diese Zahlen stammen von den Tätern und sind nicht unabhängig bestätigt.

Der eigentliche Skandal: API-Keys im Frontend

Interessanter als die Menge ist der Einstieg. FulcrumSec gibt an, keinen Server gehackt zu haben. Stattdessen hätten im öffentlich ausgelieferten JavaScript der drei Flughafen-Websites API-Schlüssel für die Marketing-Plattform Iterable gesteckt – und zwar Schlüssel mit administrativen Rechten. Wer in seinem Browser die Entwicklerwerkzeuge öffnet, sieht diesen Code. Kein Login, kein Exploit, keine Schadsoftware.

Diese Darstellung stammt von den Angreifern; MAG hat sich dazu nicht geäußert. Sie ist aber technisch plausibel und passt zu einem Muster, das wir hier im Blog schon mehrfach hatten – etwa bei den 768 geleakten AWS-Zugängen mit Adminrechten. Der Fehler ist immer derselbe: Ein Geheimnis, das nur serverseitig existieren dürfte, landet im Client.

Was das für dich bedeutet

Aus CISO-Sicht sind hier drei Dinge bemerkenswert. Erstens: Der Datenabfluss lief über einen Drittanbieter, nicht über die Kernsysteme des Flughafens. Genau solche Marketing-, Newsletter- und CRM-Plattformen liegen bei den meisten Unternehmen außerhalb des Blickfelds der IT-Sicherheit – sie werden von Marketing-Teams eingekauft und konfiguriert. Wer eine Lieferantenrisiko-Bewertung macht, sollte diese SaaS-Dienste genauso ernst nehmen wie den eigenen Active-Directory-Forest.

Zweitens: Ein API-Key im Browser-Code ist kein exotischer Fehler. Ich habe das in 25 Jahren IT in Web-Projekten jeder Größe gesehen. Meist entsteht es, weil ein Entwickler „nur schnell” eine Funktion testen wollte und der Schlüssel dann im Build blieb. Build-Tools wie Vite oder Create React App schreiben alle Umgebungsvariablen mit dem Präfix VITE_ bzw. REACT_APP_ ins Frontend-Bundle – wer einen Server-Key so benennt, liefert ihn an jeden Browser aus.

Drittens: Für die Betroffenen ist der Schaden nicht „nur eine E-Mail-Adresse”. Eine Kombination aus Namen, Kennzeichen, Parkzeitraum und Buchungsreferenz ist perfektes Material für gezieltes Phishing oder Anrufe im Namen des Flughafens. Britische Postleitzahlen grenzen zudem oft nur eine Handvoll Häuser ein.

Konkrete Praxis-Tipps

Frontend-Code nach Geheimnissen scannen: Öffne deine eigenen Websites im Browser, Reiter „Netzwerk”/„Quellen”, und suche in den JS-Bundles nach Begriffen wie api_key, token, secret oder den Namen deiner SaaS-Anbieter. Automatisiert geht das mit Secret-Scannern wie gitleaks oder TruffleHog – im Repository und im ausgelieferten Build.
Nur Public Keys ins Frontend: Viele Plattformen unterscheiden zwischen öffentlichen Client-Keys mit minimalen Rechten und Server-Keys. Alles, was lesen, exportieren oder Nutzer verwalten kann, gehört hinter ein eigenes Backend.
Drittanbieter-Inventar führen: Welche SaaS-Dienste halten Kundendaten? Wer verwaltet deren Zugänge? Werden Keys rotiert, wenn Mitarbeiter gehen?
Als Betroffener: Prüfe deine Adresse auf haveibeenpwned.com. Rechne mit Phishing-Mails oder Anrufen, die deine Buchung oder dein Kennzeichen nennen. Ein Flughafen fragt nie nachträglich nach Kartendaten. Für die wichtigsten Konten schützt ein Hardware-Security-Key nach FIDO2 zuverlässig vor Phishing – selbst wenn die Angreifer deinen Namen und deine Reisedaten kennen.

Einordnung

MAG hat offenbar nicht gezahlt, und das wäre richtig so. Erpressergruppen wie FulcrumSec verschlüsseln nichts mehr, sie stehlen und drohen. Wer zahlt, finanziert das nächste Opfer und hat trotzdem keine Garantie. Die eigentliche Lehre ist eine andere: Der größte bekannte Datenabfluss bei einem britischen Flughafenbetreiber brauchte weder Zero-Day noch Insider – nur einen vergessenen Schlüssel im Quelltext. Das ist keine Frage des Budgets, sondern der Sorgfalt.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden

Manchester Airports Datenleck: 8,8 Millionen Reisende – der Schlüssel lag im JavaScript