Nine Years of Passport and Flight Data Sat Behind Default Credentials
The first door said no. The second route still led to nine years of passport and flight data.
Security researchers found an Elasticsearch cluster containing 220,783,700 passenger and crew records that could be reached through a chain of misconfigurations. A direct request returned an HTTP 401 “Unauthorised” response, but a cloud-based path exposed the cluster and it accepted default credentials.
The records covered travel from January 2017 to April 2026. They included names, dates of birth, sex, nationality, passport or other travel-document numbers, expiry dates and issuing countries. Flight numbers, airlines, airports, seats, baggage references and scheduled, estimated and actual flight times appeared alongside that identity data.
The scale is extraordinary, but the number must be read correctly. It represents 220,783,700 travel records, not 220 million confirmed victims or unique travellers. A frequent passenger or crew member may appear many times.
Kinryū Labs linked the infrastructure to Vietnam because the cluster was hosted in Viettel-assigned IP space in Hanoi. Neither the researchers nor BleepingComputer confirmed which organisation owned or operated it. The finding therefore does not establish that Viettel, the Vietnamese government or any airline was responsible for the database.
The data was built for border decisions
Advance Passenger Information, usually shortened to API or APIS, is not ordinary loyalty-programme data. It is collected around check-in and transmitted so border authorities can assess passengers and crew before arrival or departure.
The International Civil Aviation Organization describes API as identity data that includes a person’s full name, date of birth, gender, citizenship and travel-document details. Current European rules also describe flight, seat and baggage information as part of the data that may accompany an API record.
That combination makes the exposure more consequential than a list of names and email addresses. Passport data can support identity fraud and convincing impersonation. Travel history can reveal relationships, routines and sensitive destinations. A precise itinerary can make a phishing message sound like information only an airline, border agency or travel provider should know.
The records also crossed organisational boundaries. BleepingComputer says the database contained flights from numerous airlines across Asia-Pacific, Europe and the Middle East, and sample data included several nationalities. There is no indication that the named airlines operated the exposed system or that their own networks were compromised.
A 401 response was not the security boundary
Kinryū Labs found the cluster on 3 June while surveying exposed databases for ransomware research. The cluster was named pax-info, held 29 indices and contained roughly 107 GB of data. Its main passenger index held 210,318,069 entries, while the crew index held 10,465,631.
The researchers told BleepingComputer that reaching the data required two weaknesses to line up. The internet-facing endpoint rejected direct access. A separate cloud path nevertheless reached the service, where default credentials worked.
This is the architectural lesson. A protective response on one route says nothing about every other route to the same backend. Security teams that test only the public hostname may see a reassuring authentication challenge while an alternate cloud address, load balancer, proxy or management path applies weaker controls.
Default credentials turn that routing mistake into a data exposure. They also suggest that the identity boundary around the database depended on how traffic arrived, rather than on an independently enforced control at the data layer.
The records are nine years old. The exposure period is unknown
Internet-intelligence service FOFA first recorded the host and port in October 2022 and identified the service as a database in July 2023. That history does not prove the passenger records were retrievable throughout that period. Kinryū Labs could not determine when the second access path became available.
The distinction matters. The database contains records spanning more than nine years, but that is not the same as nine years of continuous public exposure. Any incident assessment should keep data age, service visibility and confirmed accessibility as separate timelines.
Kinryū Labs began notifying Vietnamese authorities, airlines and national incident-response teams on 3 June. The researchers say access was remediated on 8 June. Singapore Airlines helped coordinate the response, but there is no evidence that it owned the system.
No logs means there is no clean answer about theft
The researchers found no ransom note, unfamiliar indices or known sale of the dataset. That is useful negative evidence, but it is not proof that nobody copied the records.
Without server logs, Kinryū Labs could not reconstruct who accessed the cluster before it was secured. Data theft therefore remains unconfirmed and cannot be ruled out. BlackTree is describing this as a data exposure, not a confirmed breach.
That evidentiary gap resembles a recurring problem in incident reporting. BlackTree previously examined how Nutex knew data left its network but could not identify whose information was taken. Here, the uncertainty begins even earlier: the absence of usable logs prevents a reliable answer about whether an unauthorised download occurred at all.
What aviation and data owners should verify
- Inventory every public, cloud, private-link, proxy and management route to passenger-data stores. Test the backend through each route, not only the official hostname.
- Remove default credentials and require centrally managed, unique authentication at the database itself. Restrict the service to explicit application identities and networks.
- Search cloud configuration, DNS, certificates, load-balancer rules and infrastructure code for alternate paths that bypass the intended access layer.
- Enable tamper-resistant access logging outside the database host. Retain enough history to investigate slow or delayed discoveries.
- Separate API, PNR and operational flight data according to purpose and retention need. Old records should not remain available merely because storage is inexpensive.
- Monitor for unusual queries, bulk exports and high-volume reads. Alert on access using factory or default identities.
- Prepare a coordinated notification process that identifies the data controller, processors, airlines and affected jurisdictions without assuming that every airline represented in a record operated the exposed system.
- Warn potentially affected travellers about targeted impersonation without claiming confirmed theft. Passport replacement decisions should follow competent government guidance.
Organisations should also verify what evidence survives after remediation. Closing a route is essential, but deleting the only logs or rebuilding the service before evidence is preserved can make the central incident question impossible to answer.
The uncomfortable lesson is hidden in the first response
An HTTP 401 response looks like a control doing its job. In this case, it described one route, not the whole system.
The most important number may not be 220,783,700. It may be two: two paths to the same sensitive service, with different security outcomes. The passenger database was protected or exposed depending on which door the request used.
Aviation systems concentrate identity and movement data because governments and carriers need it to make timely decisions. That operational value creates a correspondingly valuable target. When the data layer trusts a default password and the network offers an alternate route, an apparently closed door becomes theatre.
Questions about the Vietnam-linked APIS exposure
Were 220 million people exposed?
Not necessarily. The cluster contained 220,783,700 passenger and crew records. The same person may appear in multiple records for different journeys.
Was the database operated by the Vietnamese government?
That has not been confirmed. The Vietnam link is based on the cluster’s location in Viettel-assigned IP space in Hanoi. The owner and operator remain unidentified.
Was the information stolen?
There is no confirmed evidence of a malicious download, sale or ransom attempt. The absence of server logs means unauthorised copying cannot be ruled out.
Sources and further reading
- BleepingComputer: 220 million traveler records exposed in Vietnam-linked APIS leak, published 8 September 2026 at 03:35:50 ET.
- Kinryū Labs, the research group that discovered and reported the exposure. Its detailed technical report had not been published when this article was prepared.
- ICAO: API Guidelines and PNR Reporting Standards, accessed 8 September 2026.
- EUR-Lex: Collection and transfer of advance passenger information, accessed 8 September 2026.
This article provides general security information. It is not legal, identity-protection or incident-response advice.
