An Elasticsearch cluster named pax-info, holding Advance Passenger Information System (APIS) data for everyone who flew into, out of or through Vietnam between January 2017 and April 2026, was reachable from the internet using unchanged factory login credentials. Kinryū Labs found it on 3 June 2026 and published a TLP:CLEAR report; BleepingComputer broke the story on 8 September 2026 and Security Affairs corroborated it the same day. The cluster carried 29 indices and roughly 107 GB of data, with two principal indices holding 210,318,069 passenger records and 10,465,631 crew records, a combined 220,783,700 entries. Three months after the cluster was closed, no organisation has publicly acknowledged operating it.
What Happened
Kinryū Labs researcher Davis Zheng described the discovery as a byproduct of a broad survey of exposed databases conducted as part of research into ransomware activity. The cluster was hosted in IP space assigned to Viettel, Vietnam's largest telecommunications operator, in Hanoi. Kinryū Labs, BleepingComputer and Security Affairs all state explicitly that the operator of the system was never confirmed, and that Viettel IP assignment establishes hosting, not ownership.
Disclosure was immediate. Kinryū Labs notified Vietnamese authorities, national CERT teams and affected airlines on 3 June. Access was closed by 8 June, five days later. Singapore Airlines' security team assisted in coordinating the response, according to an authenticated email reviewed by BleepingComputer and repeated in secondary coverage.
Accounts differ on how long the data was actually reachable. The "nine years" figure that has dominated headlines describes the span of the data (7 January 2017 to 30 April 2026), not a verified nine-year exposure window. QPulse states plainly that the exact duration of the exposure remains unknown. WebProNews reports that the internet scanning service FOFA first observed the host in 2022 and classified it as a database in 2023, which would establish a multi-year window but not a nine-year one. Treat the exposure duration as at least three years by scanner evidence, with the upper bound unestablished.
Researchers found no ransom notes, no signs of database alteration, and no evidence that the data has surfaced on dark web markets. Absence of evidence here is weak: a read-only Elasticsearch endpoint accessed with valid-looking default credentials leaves very little forensic residue.
What Was Taken
Nothing is confirmed as exfiltrated by a third party. Kinryū Labs' own enumeration was deliberately read-only, limited to aggregate counts, the date range, the field schema and a small number of screenshots with names, passport numbers and dates of birth redacted. The firm states no individual record was retained, published or shared beyond the authorities notified during disclosure, and that the host address, port and credential were withheld.
What was exposed is the more useful question. Per BleepingComputer, Security Affairs and the Kinryū Labs report, each record combined identity and itinerary fields:
- Full name, date of birth, sex, nationality
- Passport or travel-document number, document expiration date, issuing country
- Flight number and date, operating airline
- Departure, destination and transit airports
- Seat assignment and baggage reference
- Scheduled, estimated and actual flight times
Kinryū Labs counted 1,008 airlines represented in the data; WebProNews renders this as "nearly 1,000 airlines." Sample records reviewed by BleepingComputer included travellers of Korean, Chinese, Canadian and New Zealand nationality. Kinryū Labs cites reach from Aeroflot and Belavia crews to Belarusian tourists in Cam Ranh. Coverage spans Asia-Pacific, European and Middle Eastern carriers.
One correction that most headlines skip, and that both Security Affairs and Tech Insider make explicitly: 220,783,700 is a count of travel records, not people. Frequent flyers and working crew appear many times over nine years. The true affected population is smaller than the headline number, though Tech Insider assesses it as still "likely in the tens of millions." No source has published a deduplicated figure.
Why It Matters
APIS data is not a loyalty programme dump. It is the regulated feed airlines are legally required to transmit to border authorities before an international flight departs. Nobody in this dataset opted in, and as Hardware Busters puts it, there was no box to untick. The population is non-consenting and global.
The field combination is what makes this dangerous. A passport number paired with name, date of birth, issuing country and expiry date is a near-complete identity document reconstruction, and unlike a password it cannot be rotated. Add nine years of itineraries with seat numbers and transit airports and the same corpus supports pattern-of-life analysis: who travelled together, who flew repeatedly to which city, which crews worked which routes. For intelligence services, that is a targeting dataset. For fraud operators, it is durable KYC bypass material.
The unresolved ownership question is the second-order problem. Tech Insider frames it as a regulatory headache rather than a technical one, and that framing holds: with no confirmed operator, there is no identifiable data controller, no notification obligation triggered, and no route for a Korean, Canadian or New Zealand traveller to determine whether they are in the file. Nine years of border-control data has effectively been orphaned in public.
The Attack Technique
There is no exploit here, and no evidence of a software vulnerability. Kinryū Labs classifies the issue as CWE-1392 (Use of Default Credentials) against Elasticsearch 8.3.3.
The failure was a chained misconfiguration across two access paths to the same cluster. The direct internet-facing endpoint behaved correctly and returned HTTP 401 on unauthenticated requests. A second, cloud-side route to the same cluster did not enforce the same control and accepted the Elasticsearch factory-set username and password, which the operator had never changed. As Hardware Busters observes, the direct 401 looks like a lock right up until you find the second door.
This is the defining pattern, and it generalises well beyond this victim. The front door tested fine. Any scan, any audit, any pen test that probed the public endpoint would have returned a clean result. The exposure lived entirely in an alternate path that was never enumerated as part of the asset's attack surface.
What Organizations Should Do
- Enumerate every network path to each datastore, not just the primary one. Inventory public endpoints, cloud-native routes, load balancer backends, VPC peering paths, service meshes and management interfaces. Confirm each path independently enforces authentication. A 401 on one route proves nothing about the others.
- Sweep for default credentials on data-tier software specifically. Elasticsearch, OpenSearch, MongoDB, Redis, Kafka and their managed equivalents. Treat any factory credential still accepted anywhere as an active incident, not a finding.
- Apply data retention limits to regulatory feeds. Nine years of APIS records in one live, queryable cluster converted a routine misconfiguration into one of the largest travel-data exposures documented. Archive cold data offline, encrypted, and separated from production search infrastructure.
- Instrument authentication telemetry on datastores and alert on successful default-credential logins. The reason nobody can say how many parties accessed this cluster is that the access logging to answer that question did not exist or was not retained.
- Assign a named owner to every internet-reachable asset before it ships. The three-month ownership vacuum here is the direct consequence of infrastructure that no team was accountable for. Ownership metadata is an incident response control, not a paperwork exercise.
- For aviation and travel operators: audit what you transmit and what your partners retain. There is no evidence that any listed airline operated this system or suffered a network breach. Carriers still fed it. Contractually establish where APIS submissions land, how long they persist, and who secures them downstream.
Sources: 220 Million Passenger Records Exposed: How Default Credentials and... | 220 million traveler records exposed in Vietnam-linked APIS leak | Massive Vietnam-Linked APIS Database Exposes Passport and ... | 220 Million Traveller Records: A Vietnam-Linked Passenger Database... | Exposed Elasticsearch Database Leaks 220.8 Million Vietnam APIS Pas... | The Vietnam APIS Leak Put 220 Million Passport Records Online, and... | Vietnam APIS Breach: No Owner Claims 220M Records | 220M Traveler Records Exposed in Airline Data Leak