220 Mio. APIS-Datensätze offen: Passnummern und die unklare Controller-Frage

Stellen Sie sich vor: Ihr Reisepass. Der Stempel aus Hanoi. Der Flug von Seoul nach Frankfurt. Sitzplatz 23A. Gepäckstück mit Tag. Und dann – ein offener Suchindex irgendwo in der Cloud, in dem genau diese Zeile steht. Name. Geburtsdatum. Passnummer. Ablaufdatum. Nationalität. Airline. Abflug. Transit. Ankunft. Geschätzte und tatsächliche Zeiten. Nicht als geleakte PDF. Nicht als Screenshot. Als Datensatz. Abfragbar. Indexiert. Über Jahre hinweg.

Plot Twist: Das war kein hypothetisches Szenario. Das war Realität – für Hunderte Millionen Reisevorgänge. APIS-Daten. Advance Passenger Information. Passagiere und Crew. Ein Cluster namens pax-info. Über 220 Millionen Einträge. Etwa 107 Gigabyte. Und eine Controller-Frage, die so unklar ist, dass die DSGVO-Uhr möglicherweise tickt, ohne dass klar ist, wer sie überhaupt starten muss.

Willkommen im Krimi der digitalen Reisefreiheit. Spoiler: Der Pass war nie nur Papier.

Was APIS wirklich speichert – und warum das brisant ist

APIS steht für Advance Passenger Information System. Kurz gesagt: Behördlich und betrieblich genutzte Vorabinformationen zu Reisenden. Airlines und Grenzsysteme tauschen diese Daten aus, damit Identitäten und Flugbewegungen vor dem Boarding und bei der Einreise geprüft werden können. Klingt technisch. Klingt bürokratisch. Klingt – wenig überraschend – nach einem Datenschatz, den niemand ungeschützt in der Wildnis lassen sollte.

Denn APIS ist kein Newsletter-Verteiler. Es ist Identität plus Bewegung. Wer Sie sind. Wann Sie fliegen. Wohin. Mit welchem Dokument. Mit welchem Sitz. Mit welchem Gepäck. Das Pikante daran – und ja, das Pikante daran: Gerade die Kombination aus Passdaten und Reiseverlauf macht aus einzelnen Feldern ein Profil. Nicht nur „jemand war unterwegs“. Sondern: wer, wann, wohin, mit welchem Ausweis.

Wer sich fragt, warum solche Systeme überhaupt so viele Felder brauchen, findet die Antwort in der Logik der Grenz- und Sicherheitsprozesse. Ohne Vorabdaten stockt der Fluss. Mit Vorabdaten entsteht aber zugleich ein hochsensibler Datensatz – und damit eine Verantwortung, die nicht im Serverraum endet.

Die Zahlen: 220.783.700 Einträge und ein Index namens pax-info

Die Forscher von Kinryū Labs – berichtet unter anderem über BleepingComputer – beschreiben ein Elasticsearch-Cluster unter dem Namen pax-info. 29 Indizes. Rund 107 Gigabyte. Und die Summe, die im Titel steckt: 220.783.700 Einträge. Darunter 210.318.069 Passagierdatensätze und 10.465.631 Crew-Datensätze.

Wichtig für die Dramaturgie – und für die Realität: Es handelt sich um Reisevorgänge, nicht um eindeutige Personen. Ein und dieselbe Person kann mehrfach auftauchen. Unterschiedliche Flüge. Unterschiedliche Jahre. Unterschiedliche Rollen. Die Zahl ist dennoch enorm. Der Zeitraum ebenso: Januar 2017 bis April 2026.

Überraschung: In diesen Indizes stecken nicht nur asiatische Airlines. Die Stichproben umfassen unter anderem koreanische, chinesische, kanadische und neuseeländische Nationalitäten – und Airlines aus dem asiatisch-pazifischen Raum, aus Europa und aus dem Nahen Osten. Die Geografie der Daten ist international. Die Hosting-Spur führt nach Hanoi, in den IP-Raum von Viettel. Der Betreiber? Von BleepingComputer nicht bestätigt. Offen. Unklar. Genau dort beginnt der juristische Thriller.

Feldinventar: Identität und Reiseverlauf in einem Index

Was genau lag offen? Die Inventarliste liest sich wie die Checkliste eines Grenzbeamten – plus Flugplan plus Sitzplatzplanung.

Zur Identität: Name. Geburtsdatum. Geschlecht. Nationalität. Pass- bzw. Reisedokumentnummer. Ablaufdatum. Ausstellungsland.

Zur Reise: Flugnummer und Flugdatum. Airline. Abflug-, Ziel- und Transitflughäfen. Sitzplatz. Gepäckinformationen. Geplante, geschätzte und tatsächliche Zeiten.

Der Clou: Jedes einzelne Feld mag für sich genommen „nur“ ein Datenelement sein. Zusammen ergeben sie eine narrativ vollständige Reisebiografie. Wer will, kann daraus Muster lesen. Wer böswillig will, kann daraus Identitätsrisiko und Bewegungsrisiko ableiten. Art. 34 DSGVO denkt genau in solchen Hochrisiko-Kombinationen – dazu später.

Die Forscher sollen eigene Vietnam-Reisedaten in den Indizes wiedergefunden und so die Authentizität der Bestände überprüft haben. Das ist der Moment, in dem aus „irgendein Leak“ ein „das betrifft echte Menschen“ wird. Kein abstrakter Datensatz. Ein Spiegel.

Timeline: Von FOFA 2022 bis Remediation am 8. Juni

Die Chronologie ist ein Lehrstück über Schatten und Latenz.

FOFA soll den Host und den Port seit Oktober 2022 gesehen haben. Als Datenbankdienst sei der Dienst ab Juli 2023 erkennbar gewesen. Wann genau die Daten über einen zweiten Weg abrufbar wurden – unklar. Die Expositionsdauer bleibt damit ein offenes Kapitel. Nicht „seit gestern“. Nicht „seit einer Stunde“. Sondern: möglicherweise lange – ohne dass die Öffentlichkeit davon wusste.

Gemeldet wurde der Fund den Angaben zufolge ab dem 3. Juni. Remediatiert am 8. Juni. Dazwischen: Koordination. Singapore Airlines soll Parteien eingebunden und die Eindämmung mitgestaltet haben – obwohl SIA das System nicht betrieben und es keine Hinweise darauf gegeben haben soll, dass Airline-Netze selbst kompromittiert waren. Das ist der Plot Twist der Verantwortungskette: Wer hilft, muss nicht der Betreiber sein. Wer Daten liefert, muss nicht der Host sein. Wer den Schaden begrenzt, muss nicht der Controller sein. Oder doch?

Unklar blieb laut Berichterstattung auch, ob Daten exfiltriert oder verkauft wurden. Keine bekannten Lösegeldforderungen. Ungewöhnliche Indizes, die nicht zum bekannten Erpressungs-Skript passen. Keine abschließenden Log-Beweise für eine Kopie. Das Fehlen von Beweisen ist kein Freispruch. Es ist nur – wenig überraschend – keine Gewissheit.

Die Berichterstattung von BleepingComputer vom 8. September 2026 fasst den Fall zusammen; Details und Einordnung finden sich in der Originalmeldung bei BleepingComputer zur APIS-Exposition.

Misconfiguration ohne Rezept: Der High-Level-Blick

Hier endet die technische Detailtiefe bewusst. Keine Zugangsbeschreibungen. Keine Abfrageketten. Keine Authentifizierungsrezepte. Nur die Struktur der Geschichte, soweit sie für die öffentliche Debatte relevant ist.

Forschende sollen über eine Kette von Fehlkonfigurationen an ein Elasticsearch-Cluster gelangt sein. Ein öffentlicher Endpunkt antwortete demnach mit HTTP 401 – also mit einer Authentisierungsaufforderung, nicht mit offener Tür. Über einen separaten Cloud-Pfad soll anschließend eine schwache bzw. standardnahe Authentifizierung akzeptiert worden sein. Mehr braucht die Öffentlichkeit nicht, um das Muster zu verstehen. Weniger wäre Verharmlosung.

Das Muster heißt: Sichtbarkeit ist nicht gleich Sicherheit. Ein Endpoint, der „401“ sagt, ist nicht automatisch „geschützt genug“. Ein zweiter Pfad kann die Dramaturgie kippen. Und Elasticsearch – als Such- und Analyseschicht über großen Beständen – ist genau dann gefährlich, wenn Indizes, Rechte und Netzgrenzen nicht hart genug gezogen sind.

Für Unternehmen lautet die Lehre nicht „wie kam man rein“. Sondern: Welche Schattenpfade existieren neben dem offiziellen Frontend? Welche Default-Zustände überleben Deployments? Welche Monitoring-Lücken lassen Expositionen Jahre lang unbemerkt?

Wer betrieb das System? Die unklare Controller-Frage

Hosted in Viettel-IP-Raum in Hanoi. Betreiber von BleepingComputer unbestätigt. Airlines liefern Passagierdaten in APIS-Logik. Ein Koordinator – hier SIA in der Remediation – muss nicht der Systembetreiber sein. Und genau hier explodiert die DSGVO-Frage.

Wer ist Verantwortlicher im Sinne der Datenschutz-Grundverordnung? Wer ist Auftragsverarbeiter? Wer entscheidet über Zwecke und Mittel der Verarbeitung? Airlines, die Passagierdaten erheben und an Grenz- bzw. Informationssysteme übermitteln? Der Betreiber der APIS-Infrastruktur, der Indizes hält und suchbar macht? Beide – in gemeinsamer Verantwortung?

Das Pikante daran: Solange die Rollen unklar sind, ist auch unklar, wer die Meldepflicht nach Art. 33 DSGVO überhaupt schuldet. Und wann die 72-Stunden-Uhr anläuft.

Journalistische Analyse, kein Rechtsrat: Die folgenden Abschnitte ordnen Fragen, die Aufsichtsbehörden, Datenschutzbeauftragte und Vertragsjuristinnen in solchen Fällen typischerweise stellen. Sie ersetzen keine Einzelfallprüfung.

Art. 33 und die 72-Stunden-Uhr: Wann tickt sie für wen?

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2PromptPhotorealistic editorial photo of blurred airport departure boards and gates with digital systems glow in a modern terminal hall, travel infrastructure atmosphere, no readable flight numbers, no logos, no text overlay, cool ambient light, documentary tech magazine look, 16:9

Art. 33 DSGVO verlangt, dass der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt geworden ist, der zuständigen Aufsichtsbehörde meldet – sofern die Verletzung voraussichtlich ein Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat.

Der Trigger heißt „bekanntwerden“. Nicht „technisch möglich gewesen“. Nicht „irgendwo im Internet sichtbar“. Sondern: Wann wird dem jeweiligen Akteur die Verletzung bekannt?

Szenario A – Betreiber der Infrastruktur: Wenn Forschende melden, wenn ein Security-Team einen Hinweis erhält, wenn ein Monitoring-Alarm greift. Ab diesem Moment kann die Uhr für den Betreiber laufen – sofern er Verantwortlicher ist oder als solcher agiert.

Szenario B – Airlines: Wenn sie benachrichtigt werden, dass „ihre“ Passagier- und Crew-Daten in einem exponierten Cluster lagen. Kennen sie den Vorfall erst durch die Koordination – etwa über SIA oder Behördenkontakte –, kann ihr „bekanntwerden“ später liegen als das des Betreibers. Unterschiedliche Uhren. Unterschiedliche Startzeiten. Unterschiedliche Meldewege.

Szenario C – Behörden: Aufsichtsbehörden und Grenzbehörden können eigene Kenntnisstände haben. Das ändert nicht automatisch die Meldepflicht der Verantwortlichen, kann aber die politische und regulatorische Dynamik beschleunigen.

Überraschung für viele Compliance-Teams: Die Unklarheit über den Controller verzögert nicht nur die Meldeentscheidung. Sie erzeugt selbst Risiko – weil jede Stunde ohne klare Zuständigkeit die Chance auf fristgerechte, kohärente Meldung verringert. Wer wartet, bis „irgendjemand“ den Hut aufsetzt, riskiert, dass die 72 Stunden für jemanden längst laufen.

Parallelen zu Dienstleister-Vorfällen sind hier kein Zufall. Wenn Kundendaten bei einem Partner liegen und der Vorfall dort passiert, stellt sich dieselbe Frage: Wann weiß der Auftraggeber Bescheid – und was verlangen Verträge, AVV und Eskalationsketten? Der Lidl-Dienstleister-Komplex zeigt in anderer Branche, wie schnell Verantwortung in Lieferketten verschwimmt und wie teuer Unklarheit wird.

Airlines vs. Betreiber: Zwecke, Mittel, gemeinsame Verantwortung

Airlines erheben Passagierdaten für Beförderung, Sicherheit und gesetzliche Übermittlungspflichten. Sie entscheiden über Zwecke der eigenen Erhebung. Der APIS-Infrastrukturbetreiber entscheidet über Speicherung, Indexierung, Suchbarkeit, Hosting-Standort, Zugriffspfade. Das klingt nach klassischer Trennung: Verantwortlicher hier, Auftragsverarbeiter dort – sofern ein wirksamer Auftragsverarbeitungsvertrag die Mittel bindet.

Aber: Entscheidet der Betreiber eigenständig über zusätzliche Zwecke – Analyse, Langzeitspeicherung über Jahre, Crew- und Passagier-Pooling in einem Suchcluster –, kann die Rolle kippen. Dann ist er nicht nur „die IT“, sondern mitentscheidend über Zwecke und wesentliche Mittel. Dann rückt Art. 26 DSGVO in den Blick: gemeinsame Verantwortlichkeit, transparente Vereinbarung, wer welche Informationspflichten erfüllt.

Singapore Airlines als Koordinator der Eindämmung ohne Betrieb des Systems illustriert die operative Realität: Airlines können betroffen und handlungsfähig sein, ohne den Server zu besitzen. Das entlastet sie nicht automatisch von Controller-Fragen zu den Daten, die sie eingebracht haben. Es zeigt nur, dass Remediation und rechtliche Rolle nicht deckungsgleich sein müssen.

Für EU-Reisende kommt die territoriale Dimension hinzu. Art. 3 DSGVO – räumlicher Anwendungsbereich – kann greifen, wenn Verantwortliche in der Union niedergelassen sind oder wenn Verarbeitungen das Anbieten von Waren/Dienstleistungen an Betroffene in der Union oder die Beobachtung ihres Verhaltens betreffen. Vietnam-Hosting ändert nicht magisch die Frage, ob EU-Personen betroffen sind und ob unionsrechtliche Pflichten bestehen. Journalistisch gesprochen: Die Serveradresse ist nicht der einzige Kompass. Die Betroffenenadresse zählt mit.

Wieder: Analyse, kein Gutachten. Grenzüberschreitende APIS-Ketten sind komplex. Genau deshalb brauchen Verträge und Rollenklarheit vor dem Vorfall – nicht danach.

Art. 34: Hochrisiko Passnummer plus Geburtsdatum plus Reiseroute

Art. 34 DSGVO verlangt unter bestimmten Voraussetzungen die Benachrichtigung der betroffenen Personen – insbesondere wenn die Verletzung voraussichtlich ein hohes Risiko für deren Rechte und Freiheiten zur Folge hat.

Passnummern. Geburtsdaten. Nationalität. Flugmuster über Jahre. Das ist kein vergessenes Marketing-Opt-in. Das ist Identitätsmaterial plus Bewegungsbild. Phishing mit echten Reisedetails. Identitätsmissbrauch. Profiling von Reisegewohnheiten. Erpressungsszenarien. Die Risikoliste schreibt sich von selbst.

Ob im konkreten Fall eine Benachrichtigungspflicht greift, hängt von Faktoren ab, die öffentlich nicht abschließend geklärt sind: Exfiltrationsnachweis, Schadenswahrscheinlichkeit, getroffene Schutzmaßnahmen, Erreichbarkeit der Betroffenen. Was klar ist: Die Kategorie der Daten spricht nicht für Bagatelle. Wer hier „kein Risiko“ murmelt, ignoriert den Inhalt der Felder.

Und noch einmal der Clou der Controller-Frage: Wer soll benachrichtigen, wenn unklar ist, wer Verantwortlicher ist? Wer besitzt die Kontaktdaten der Betroffenen? Die Airline? Der Systembetreiber? Beide? Ohne vorab definierte Benachrichtigungsketten wird Art. 34 zur organisatorischen Falle.

Wer den regulatorischen Druck hinter solchen Fällen verstehen will, findet im Überblick zu DSGVO-Enforcement und Datenhandel den größeren Kontext: Aufsicht, Handel mit geleakten Identitäten, Unternehmenswissen als Pflicht.

Enterprise-Lektionen: AV-Verträge, Schattensysteme, Elasticsearch-Hygiene

Was nehmen Organisationen mit – jenseits von Reisepass-Romantik und Grenztechnik?

Erstens: Rollen vor dem Vorfall klären. Wer ist Verantwortlicher? Wer Auftragsverarbeiter? Gibt es gemeinsame Verantwortlichkeit? Steht das in Verträgen – greifbar, nicht nur in Präambeln? Ohne AVV und klare Eskalation bleibt die 72-Stunden-Uhr ein Ratespiel.

Zweitens: Schattensysteme kartieren. Ein Cluster namens pax-info, über Jahre befüllt, international relevant, und dennoch mit unklarer öffentlicher Betreiberattribution – das ist das Menetekel. Inventar. Ownership. Lifecycle. Löschkonzepte. Wer Indizes über 2017 bis 2026 hält, braucht eine Antwort auf „warum so lange“ und „wer darf suchen“.

Drittens: Expositionshygiene für Such- und Analyseschichten. Elasticsearch und vergleichbare Systeme leben von Zugänglichkeit für Analyse. Genau deshalb brauchen sie harte Netzgrenzen, starke Authentifizierung, minimale Rechte, kontinuierliche Außenperspektive. Nicht als Checklisten-Theater. Als Überlebensreflex. Die Story hier ist High-Level: Ein Pfad forderte Authentisierung, ein anderer Pfad war der schwache Punkt. Das reicht als Warnung.

Viertens: Meldeketten testen. Tabletop. Wer ruft wen an? Wer meldet an welche Aufsicht? Wer informiert Partner-Airlines? Wer entscheidet über Art. 34? Der DSGVO-Stresstest, wenn das Datenleck kommt, beschreibt genau diese Minuten- und Stundenlogik – und warum jede Stunde zählt.

Fünftens: Dienstleister-Parallelen ernst nehmen. Der Fall erinnert an Konstellationen, in denen Kundendaten bei Partnern liegen und der Auftraggeber erst spät erfährt, was passiert ist. Wer den Lidl-Dienstleister-Vorfall und Kundendaten kennt, kennt das Muster: Verantwortung endet nicht am eigenen Firewall-Rand.

Sechstens: Gesundheits- und Mega-Leak-Dynamiken im Blick behalten. Andere Branchen, gleiche Strukturfrage – Sensibilität der Daten, unklare Ketten, öffentlicher Druck. Der Blick auf den Mega-Leak bei Gesundheitsdienstleistern zeigt, wie schnell aus technischen Vorfällen gesellschaftliche und regulatorische Großlagen werden.

Noch ein Aspekt, der in der öffentlichen Debatte oft untergeht: Crew-Daten. Über zehn Millionen Einträge betreffen nicht Ticketkäuferinnen und Ticketkäufer, sondern Bordpersonal. Auch hier Name, Dokument, Flugmuster. Auch hier Identitätsrisiko. Die Trennung Passagier/Crew im Cluster ändert nichts an der Sensibilität – sie verdoppelt eher die Betroffenengruppen, die bei einer Benachrichtigungslogik mitgedacht werden müssten.

Und die Zeitspanne: Von 2017 bis 2026 bedeutet nicht nur Volumen. Sie bedeutet Historie. Alte Flüge. Alte Dokumentnummern. Möglicherweise abgelaufene Pässe neben aktuellen. Wer solche Bestände hält, speichert Vergangenheit in suchbarer Form. Das ist für Analyse praktisch. Für den Schutz absolut riskant, wenn Rechte und Netzgrenzen nicht mitwachsen.

Dass Forschende den Fund meldeten und binnen weniger Tage eine Remediation erfolgte, ist die gute Nachricht im schlechten Stück. Dass FOFA Host und Port schon seit Oktober 2022 gesehen haben soll und der Dienst ab Juli 2023 als Datenbank erkennbar gewesen sein soll, bleibt die unbequeme Pointe. Sichtbarkeit in Scannern ist nicht gleich öffentliches Drama – aber sie ist ein Hinweis, dass „wir waren unsicher, ob jemand hinsieht“ keine Strategie ist.

Für Datenschutzbeauftragte in Airlines und Reisekonzernen heißt das konkret: Fragen Sie nicht nur nach dem eigenen CRM. Fragen Sie nach jedem System, das Pass- und Flugdaten entgegennimmt, speichert, indexiert oder weiterleitet. Fragen Sie nach dem Hosting. Fragen Sie nach dem AVV. Fragen Sie nach dem Alarm, der auslöst, wenn ein Index von außen erreichbar wird. Und fragen Sie – brisant genug – wer im Zweifel die Meldung an die Aufsicht schreibt.

Was unklar bleibt – und warum das die eigentliche Gefahr ist

Unklar: der Betreiber. Unklar: ob kopiert und verkauft wurde. Unklar: die genaue Expositionsdauer über den zweiten Pfad. Unklar: für wen die Art.-33-Uhr wann startete. Klar: 220.783.700 Einträge. Klar: Pass- und Reisedaten. Klar: ein Zeitfenster von 2017 bis 2026. Klar: Remediation am 8. Juni nach Meldung ab dem 3. Juni. Klar: SIA half bei der Eindämmung, ohne das System zu betreiben.

Das ist der Krimi ohne finalen Gerichtssaal-Schnitt. Kein sauberer Bösewicht mit Visitenkarte. Kein einzelner Controller mit Namensschild. Stattdessen eine Infrastruktur, internationale Reisende, Airlines, ein Hosting-Raum in Hanoi – und eine Verordnung, die klare Verantwortliche voraussetzt, die die Realität manchmal erst nach dem Vorfall nachliefert.

Für Betroffene bleibt ein bitterer Nachgeschmack: Die eigenen Reisedaten können in Indizes landen, von denen man nie gehört hat. Für Unternehmen bleibt eine operative Wahrheit: Wer Daten teilt, muss wissen, wer sie hält – und wer meldet, wenn sie offen liegen.

Schlussbild: Der Stempel war nie nur Tinte

Zurück zum Einstieg. Passstempel. Flugverlauf. Offener Index. Die Geschichte von pax-info ist nicht nur ein Leak mit großer Zahl. Sie ist ein Stress test für die Controller-Doktrin der DSGVO. Wenn niemand klar sagt „wir sind verantwortlich“, tickt die Uhr trotzdem – nur eben für jemanden, der sich vielleicht noch nicht gefunden hat.

Plot Twist zum Abschied: Die größte Schwachstelle war vielleicht nicht der schwache Cloud-Pfad. Sondern die organisatorische Nebelwand drumherum. Brisant. Lehrreich. Und – wenig überraschend – ein Fall, der Datenschutzteams und Airline-Compliance noch lange beschäftigen wird.

Der Pass fliegt mit. Die Daten auch. Die Frage ist nur: Wer hält den Hut, wenn der Index plötzlich spricht?