An Advance Passenger Information System (APIS) database holding more than 220 million passenger and crew records was left reachable over the internet through what researchers describe as a chain of security misconfigurations, according to reporting by BleepingComputer on the findings of Kinryū Labs. The exposed cluster, named pax-info, held 29 indices and roughly 107 GB of data spanning January 2017 through April 2026, and included passport numbers, dates of birth, nationalities, and detailed itinerary data. Kinryū Labs reports the cluster was hosted in Viettel-assigned IP space in Hanoi; BleepingComputer states it could not confirm which Vietnamese organization operated the system. As of publication there is no primary statement from an operator, a Vietnamese regulator, or a national CERT confirming ownership, remediation timeline, or notification plans, and this brief should be read with that gap in mind.
What Happened
Kinryū Labs found the Elasticsearch cluster on June 3, 2026, while surveying exposed databases as part of unrelated research into ransomware activity. Rather than a single flaw, the researchers characterise the exposure as a chain of misconfigurations that left the cluster queryable from the public internet.
The counts are precise rather than estimated, which is unusual for a leak story and worth noting. The two principal indices held 210,318,069 passenger records and 10,465,631 crew records, for a combined total of 220,783,700 entries. The commonly cited "220 million" headline figure is a rounding of that exact count, not a separate estimate, so there is no competing record-count claim in this case. What is genuinely uncertain is not the number of rows but how many distinct human beings those rows represent: nine years of APIS submissions will contain heavy duplication, since a frequent flyer generates a record per leg, per journey.
APIS feeds are a border-control mechanism, not a marketing database. Airlines transmit identity, travel-document, and flight data to destination and transit states before departure or arrival. That makes the operator of such a system a government body, a state-contracted aviation authority, or a service provider acting on their behalf. BleepingComputer explicitly declined to name the operator, and no source in this set does so with attribution, so wasteland.me is not naming one either.
Coverage window matters as much as volume. Because the records run from January 2017 to April 2026, the affected population is not limited to Vietnamese nationals. Any traveler of any nationality who flew to, from, or through Vietnam in that nine-year period is plausibly in scope.
What Was Taken
There is an important distinction here that the language around this incident tends to blur: the data was demonstrably exposed, and researchers accessed it. No source in this set claims a threat actor exfiltrated the cluster, listed it on a leak forum, or attempted extortion. Absence of evidence of theft is not evidence of absence, particularly for a system that sat reachable for an unknown duration, but the confirmed fact is exposure.
The identity fields described in the reporting include:
- Full names of passengers and crew
- Dates of birth and sex
- Nationalities
- Passport or travel-document numbers
- Document expiration dates and issuing countries
The associated travel fields include flight numbers and dates, operating airline, departure, destination and transit airports, seat assignments, baggage references, and scheduled, estimated, and actual flight times.
The combination is what elevates this above a typical customer-data leak. A passport number paired with a matching name, date of birth, nationality, issuing country, and expiry date is a near-complete identity-document profile suitable for document fraud, synthetic identity construction, and know-your-customer bypass. Passport numbers are not rotatable the way a password or a payment card is; replacement means a physical reissue process, which most affected travelers will never initiate because most will never learn they were affected. Layer the itinerary data on top and the dataset also supports pattern-of-life analysis: who traveled where, when, with whom in adjacent seats, and how often.
The 10.4 million crew records deserve separate attention. Aircrew are a small, repeatedly-traveling population with predictable rosters, and a crew-linked dataset covering nine years is a targeting resource against aviation personnel specifically, not just a privacy loss for them as individuals.
Why It Matters
Border-control data is one of the highest-value categories in existence, and it sits in a governance gap. Travelers do not consent to APIS submission in any meaningful sense, cannot opt out, cannot inspect what was submitted, and have no practical route to remediation when the receiving state's system is misconfigured. The victim population here is global while the accountability, such as it is, is national.
For state-aligned intelligence collection, a nine-year record of who entered and exited a Southeast Asian transit hub is a counterintelligence product. It can be used to reconstruct travel patterns of diplomats, journalists, business executives, NGO staff, and intelligence officers, and to identify anomalous or repeated co-travel. That value does not degrade quickly; unlike credential dumps, historical travel records remain analytically useful for years.
For financially motivated actors, the passport-plus-biographical combination is durable fraud inventory. And the enrichment potential is the real long-term risk: this dataset joins cleanly against any other traveler dataset on name plus date of birth plus travel date, which is precisely the sort of correlation that turns several separately survivable leaks into a single unsurvivable profile.
The structural lesson for defenders is that the exposure required no adversary. There was no intrusion, no malware, no credential theft, no lateral movement, and therefore nothing for a detection stack to catch. A search engine for internet-facing services and a browser were sufficient. High-value data does not need a sophisticated attacker if the access control is simply absent.
The Attack Technique
Strictly, there is no attack technique on record. The reporting describes a chain of security misconfigurations leaving an Elasticsearch cluster accessible online, discovered during opportunistic scanning. The specific misconfigurations are not enumerated in the available source, and the exposure duration is not established. The known dates are the June 3, 2026 discovery and the April 2026 upper bound on the data itself; there is no stated date on which the cluster was secured.
Elasticsearch exposures follow a well-worn pattern: a cluster bound to an external interface rather than localhost, with security features unconfigured or explicitly disabled, and no upstream network control compensating for it. Because Elasticsearch speaks HTTP, an unauthenticated cluster is not merely readable but fully queryable, meaning an unauthorized party can search 220 million records for a specific individual rather than having to download and process the full 107 GB.
Worth flagging honestly: this was found by researchers surveying exposed databases in the course of ransomware research. That same scanning surface is continuously enumerated by criminal groups running identical methodology with different intent. The population of parties who could have found this cluster before June 3 is not small.
Sector Context: Adjacent Aviation Incidents
Several sources supplied for this brief cover a different incident entirely, and conflating them would be a reporting error. They are summarised here as sector context only, not as evidence about the APIS leak.
Manchester Airports Group (MAG), the UK's largest airport operator, disclosed on August 27, 2026 that an unauthorized third party accessed customer data tied to car park, lounge, and Fast Track booking systems plus in-airport Wi-Fi registrations across Manchester, London Stansted, and East Midlands airports. MAG put the affected population at approximately 8.7 million customers and emphasised that most had only an email address exposed; MAG also stated no payment-card or banking data was involved and that it has notified affected customers. Figures for the actor's claims differ across outlets: the extortion group FulcrumSec told BleepingComputer it took roughly 86 GB, and reported customer-profile counts range from "around 8.7 million" (MAG's own disclosure, per multiple outlets) to a claimed 8.67 million profiles, 2.48 million purchase records, 1.16 billion marketing events, and 108,000 vehicle registrations (FulcrumSec's claim, as reported by TechNadu). Counts for upcoming-travel records vary between "nearly 200,000" and "around 190,000" depending on the outlet. FulcrumSec claims the entry point was Iterable API credentials exposed in client-side JavaScript; MAG has not publicly confirmed either the 86 GB figure or that access path. BleepingComputer reportedly validated one traveler record from the actor's samples but could not verify the full scope. All of these actor-side claims come from OTHER-tier reporting and remain unconfirmed by the victim.
Separately, a California Attorney General breach-notification filing lists CTS Journey Holdings, LLC (DBA Corporate Travel Service) with breach dates of December 3 and December 11, 2025. That is a primary regulatory record, but it is a distinct incident with no established connection to either the APIS exposure or MAG.
The through-line across all three: travel data concentrates in a small number of intermediaries, and it leaks through boring failures. An unauthenticated database, a key shipped to every browser, a third-party travel management provider. None of these required a novel exploit.
What Organizations Should Do
Inventory and externally validate every datastore, then verify from outside your own network. Internal asset inventories routinely miss the systems that end up exposed. Scan your own external ranges the way researchers do, using an internet-wide scanning service against your allocated IP space, and specifically hunt for Elasticsearch, OpenSearch, MongoDB, Redis, and Kafka endpoints answering on public interfaces. Treat any hit as an incident, not a ticket.
Enforce authentication and TLS on search clusters as a hard gate, not a hardening step. Modern Elasticsearch ships security enabled by default; the exposures that persist are almost always older deployments, upgraded-in-place clusters, or ones where security was deliberately disabled during a migration and never re-enabled. Audit for xpack.security.enabled: false and for network bindings other than localhost, and block deployment on that condition in CI rather than detecting it afterwards.
Apply data-retention limits to regulatory and border-control feeds. Nine years of APIS records in a single hot, queryable cluster is a retention decision, and it multiplied the impact by roughly an order of magnitude over a live operational window. Define a retention period tied to the actual legal requirement, archive beyond it into cold storage that is encrypted and not network-reachable, and delete when the obligation expires.
Assume aggregation risk in vendor and government data-sharing agreements. If you are an airline transmitting APIS data, your passengers' passport numbers now sit in systems you do not operate and cannot audit. Push for contractual security requirements, evidence of independent assessment, and breach-notification obligations flowing back to you, and treat a receiving state's or provider's poor posture as a risk you own jointly.
Hunt for credentials and keys in browser-delivered code. The MAG claims, while unconfirmed by the victim, describe a failure mode any organisation can check for today: API keys embedded in client-side JavaScript. Add secret scanning to your frontend build pipeline, scope any key that must reach the browser to the absolute minimum permissions, and rotate on a schedule rather than on discovery.
Build detection for enumeration, not just intrusion. Neither of these incidents would trip a classic intrusion-detection signature. Instrument for volumetric read patterns and unusual query breadth against data stores and third-party APIs, and alert on bulk export behaviour from marketing and engagement platforms, which are consistently under-monitored relative to the sensitivity of what they hold.
For affected travelers, the practical guidance is thin and it is worth saying so plainly. Passport numbers cannot be rotated without reissue, and there is no notification mechanism for a leak of this shape. Individuals who traveled through Vietnam between 2017 and 2026 and have elevated exposure, including journalists, diplomatic staff, and executives, should assume their travel history and document details may be in circulation and factor that into future travel-security planning.
Sources: 220 million traveler records exposed in Vietnam-linked APIS leak | Submitted Breach Notification Sample State of California - Departm... | FulcrumSec Claims Manchester Airports (MAN) Hack, 86 GB Data Theft... | Manchester Airports Group Breach: FulcrumSec Publishes Alleged Stol... | Manchester Airports Group Data Breach Raises Alarming Questions Ove... | Manchester Airports Group Breach: FulcrumSec Stole 86 GB Without Ha... | FulcrumSec Claims Manchester Airports Hack, 86 GB Stolen | FulcrumSec Claims Manchester Airport Data Breach, 86GB of Data Stolen