An Elasticsearch cluster named pax-info, holding nine years of Advance Passenger Information System (APIS) data for flights into, out of and through Vietnam, sat reachable from the internet behind an unchanged factory login. Kinryū Labs found it on 3 June 2026 and published its technical report in September; the cluster held 220,783,700 records dated 7 January 2017 through 30 April 2026, split into 210,318,069 passenger records and 10,465,631 crew records across 29 indices and roughly 107 GB (Kinryū Labs, corroborated by Security Affairs, SecureBlink, Hardware Busters and Tech Insider). Kinryū counted 1,008 airlines represented in the data; WebProNews describes it as "nearly 1,000." Access was closed on 8 June 2026. As of publication, no organisation has publicly acknowledged owning the system, and there is no victim statement, regulator filing or national CERT advisory in the public record for this incident. Every account below therefore rests on the researchers' report and press coverage derived from it, not on a confirmed operator.
What Happened
Kinryū Labs was sweeping for internet-exposed databases as part of unrelated ransomware research when it turned up the pax-info cluster, running Elasticsearch 8.3.3 and classified by the researchers under CWE-1392 (use of default credentials). The host lived in IP space assigned to Viettel, Vietnam's largest telecommunications operator, in Hanoi. The researchers were explicit that this establishes hosting, not ownership: Viettel is a large provider, and Kinryū could not confirm which Vietnamese organisation ran the system.
Disclosure was fast. Kinryū notified Vietnamese authorities, national CERT teams and affected airlines on 3 June, the same day it found the cluster, and access was locked down by 8 June, five days later. Singapore Airlines' security team played a coordinating role in the response, according to an authenticated email WebProNews reports was reviewed by BleepingComputer. The story went public on 8 September 2026; Tech Insider says Kinryū disclosed to TechRadar and BleepingComputer, while other outlets credit BleepingComputer with breaking it.
How long the data was exposed is where accounts diverge in emphasis. WebProNews and QPulse report that internet scanning service FOFA first saw the host in 2022 and only identified it as a database in 2023. SecureBlink frames the same telemetry more aggressively, saying the cluster was visible to scanners since at least October 2022, nearly three years before discovery. Nobody claims to know the true exposure window: QPulse states plainly that the exact duration remains unknown, and SecureBlink reports that no access logs existed, so whether anyone copied the data before remediation cannot be established either way.
What Was Taken
Nothing is confirmed taken. What is confirmed is what was reachable, and the field list is unusually complete because APIS data is designed to be complete.
Each record paired an identity block with a full itinerary. The identity side carried full name, date of birth, sex, nationality, passport or travel-document number, that document's expiration date and its issuing country, for both passengers and crew. The itinerary side carried flight number and date, airline, departure and destination airports, transit airports, seat assignment, baggage references, and scheduled, estimated and actual flight times.
The 220.8 million figure is travel records, not people. Security Affairs, Tech Insider and Kinryū all make this point directly: a frequent flyer appears once per journey, so the number of distinct individuals is materially smaller. Tech Insider estimates the real affected population is "still likely in the tens of millions," which is an estimate, not a count, and no source has produced a deduplicated figure.
Reach is genuinely global rather than Vietnamese. The indices covered carriers across Asia-Pacific, Europe and the Middle East; Kinryū cites examples running from Aeroflot and Belavia crew to Belarusian tourists flying into Cam Ranh. Anyone who flew to, from or through Vietnam in the nine-year window is potentially in the set regardless of their own nationality.
On post-exposure activity, the reporting is consistent and negative: QPulse reports no ransom notes and no signs of database alteration, and WebProNews reports no evidence so far of the data appearing for sale on dark web markets. Absent access logs, absence of evidence is the operative caveat.
Why It Matters
APIS is not a marketing list. It is the regulatory feed airlines are legally obliged to transmit to border authorities before departure, which means travellers had no opt-out, no consent checkbox, and in most cases no idea the dataset existed. Hardware Busters puts it well: there was no box to untick. The same regulatory mandate that makes the data reliable also concentrates it, turning one misconfigured node into a near-complete movement history for a country's entire international air traffic.
The contents are durable in a way most breach data is not. A passport number with its issuing country, expiry date and holder's date of birth supports document fraud and high-quality identity impersonation for years. Combined with itineraries down to seat and baggage tag, it also supports pattern-of-life analysis: who travelled with whom, how often, on which routes. For diplomats, journalists, dissidents, corporate executives and aircrew, that is a counterintelligence problem, not a credit-monitoring problem.
Then there is the accountability gap, which Tech Insider and Hardware Busters both treat as the real story. Three months after remediation and a week after public disclosure, no airline, ministry or contractor has claimed the system. An unowned breach has no notification obligation anyone will enforce, no affected-user mailing, and no regulator with an obvious jurisdictional hook. Travellers cannot be told they were exposed because there is nobody willing to say they were the ones exposing them.
The Attack Technique
There was no exploit. There was no vulnerability in Elasticsearch to patch. The failure was a configuration asymmetry between two network paths to the same cluster.
The direct, internet-facing endpoint behaved correctly: requests to it returned HTTP 401, authentication required. That is the door defenders check, and it looked locked. A second route, described by the researchers as a cloud-based vantage point, reached the same cluster and accepted Elasticsearch's unchanged factory username and password. In Kinryū's phrasing, "it answered on its unchanged default login." Two doors, one of them never hardened, and only one of them ever audited.
This is the dominant pattern in cloud data exposures and it is worth naming precisely: authentication was not missing, it was inconsistently enforced across ingress paths. A scan of the primary endpoint would have returned a clean result every single time the cluster was exposed.
Kinryū states its enumeration was read-only and limited to aggregate counts, the date range, the field schema and a small number of screenshots with identifying fields redacted; no individual record was retained, published or shared beyond the notified authorities, and the host address, port and credential are withheld. The researchers validated authenticity by matching records against their own team members' trips to Vietnam. The report is published TLP:CLEAR.
What Organizations Should Do
- Enumerate every ingress path to each datastore, not just the obvious one. Test authentication from outside the perimeter, from inside the VPC, from any peered or cloud-side network, and from any management or proxy path. A 401 on the front door proves nothing about the side door. This single check would have caught
pax-info. - Sweep for default credentials on all data infrastructure. Elasticsearch, OpenSearch, MongoDB, Redis, Kafka and their managed equivalents all ship with known factory logins or permissive defaults. Automate the check rather than trusting a build-time runbook, and treat a default-credential hit as an incident, not a ticket.
- Turn on and retain access logging before you need it. The most damaging unknown here is not the exposure, it is that no logs existed, so copying can be neither confirmed nor ruled out. Audit logs on sensitive datastores, shipped off-host, are the difference between a scoped incident and a permanent question mark.
- Apply retention limits to regulated data. Nine years of APIS records in one live cluster is a policy decision as much as a security one. Define how long pre-departure manifests must remain hot, archive or purge beyond that, and reduce the standing blast radius.
- Monitor your own attack surface with the tools attackers use. FOFA had this host catalogued years before any defender acted on it. Shodan, Censys and FOFA queries against your own IP ranges and cloud accounts, run continuously, surface exposures on roughly the timeline adversaries see them.
- Establish ownership records for every production datastore. The reason this incident has no accountable party is that nobody can map the asset to an operator. Maintain an inventory keyed to a named owning team, and include third-party and contractor-run systems, which are the ones that go orphaned.
- For aviation and border-adjacent operators specifically, audit the vendor chain. APIS data moves through airlines, ground handlers, integrators and government systems. Contractual security requirements and evidence of configuration review should extend to every party that stores a copy.
Sources: 220 Million Passenger Records Exposed: How Default Credentials and... | 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... | Vietnam APIS Breach: No Owner Claims 220M Records | The Vietnam APIS Leak Put 220 Million Passport Records Online, and... | 220 Million Traveler Records Exposed in Vietnam-Linked APIS Leak | 220M Traveler Records Exposed in Airline Data Leak