Exposed APIS Database Reveals 220 Million Passenger and Crew Travel Records

A publicly accessible Advance Passenger Information System database exposed more than 220 million passenger and crew entries, combining passport details with flight itineraries, seat assignments, baggage references, and precise travel times.

The Elasticsearch cluster was hosted in Viettel-assigned address space in Hanoi and appears connected to a Vietnamese organization. The organization responsible for operating the system has not been identified.

Kinryū Labs discovered the cluster on June 3 while investigating exposed databases as part of ransomware-related research. Access was remediated on June 8 following notifications to Vietnamese authorities, airlines, and national incident-response teams.

There is no confirmed evidence that attackers copied or sold the information. However, the absence of server logs means unauthorized access and data exfiltration cannot be ruled out.

The database held travel data spanning more than nine years

The exposed Elasticsearch cluster was named pax-info. It contained 29 indices and approximately 107 GB of information.

Its two principal indices held:

• 210,318,069 passenger records
• 10,465,631 crew records
• 220,783,700 total travel entries

That total does not represent 220 million separate victims. APIS systems generate records for journeys, so frequent travelers and aviation personnel may appear many times. The number of unique individuals remains unknown.

The records covered travel between January 2017 and April 2026. Their international scope means the affected population is not limited to Vietnamese citizens or residents.

Researchers validated the database by matching entries against their own travel involving Vietnam. Examined samples included Korean, Chinese, Canadian, and New Zealand nationals, while the dataset referenced airlines serving Asia-Pacific, European, and Middle Eastern routes.

A complete breakdown by nationality has not been established. Potentially affected people include passengers and crew who flew to, from, or through Vietnam during the period represented in the database.

Passport data was linked directly to detailed itineraries

Advance Passenger Information Systems allow airlines to transmit identity, document, and flight information to government authorities before passengers or crew arrive in or depart from a country.

The exposed fields included:

• Passenger and crew names
• Dates of birth and sex
• Nationalities
• Passport or other travel-document numbers
• Document expiration dates and issuing countries
• Airline names and flight numbers
• Travel dates
• Departure, destination, and transit airports
• Seat assignments
• Baggage references
• Scheduled, estimated, and actual flight times

The risk comes from the combination rather than any single field. A criminal with a name and passport number gains substantially more context when those identifiers are connected to historical movements, airlines, seats, transit points, and baggage data.

Such records could support convincing impersonation attempts. A phishing message that cites a real flight, destination, seat, or travel date is more likely to persuade a recipient to open a malicious attachment, disclose credentials, or call a fraudulent support number.

The dataset could also enable profiling and surveillance. Officials, corporate executives, airline personnel, journalists, activists, and other sensitive travelers may face elevated risks when their movements can be reconstructed across multiple journeys.

Crew information presents an additional operational concern. Repeated records may reveal work patterns, frequently used routes, airports, and periods when specific personnel were traveling.

A blocked endpoint concealed an alternate route using default credentials

The exposure resulted from two configuration weaknesses working together.

Attempts to access the service directly over the internet returned an HTTP 401 Unauthorized response. That behavior made the endpoint appear protected against unauthenticated requests.

A separate cloud-based access path nevertheless provided a route to the Elasticsearch cluster. Once researchers reached it through that path, the service accepted default credentials.

This distinction matters for defenders. Testing only a primary public endpoint can produce a false sense of security when the same service remains reachable through cloud networking, proxies, alternate hostnames, management interfaces, or overlooked access routes.

The exact Elasticsearch version has not been disclosed. There is also no identified CVE associated with the incident. The known failure involved exposed infrastructure, an alternate access route, and unchanged default authentication rather than a reported software vulnerability.

Internet intelligence service FOFA first observed the host and port in October 2022. It classified the service as a database in July 2023. Those observations show that the host was externally visible, but they do not establish when the alternate route began exposing passenger information.

The records themselves extend back more than nine years, yet that does not mean the database was accessible throughout the same period. The actual exposure duration remains unknown.

Airlines in the records are not necessarily breach victims

The presence of an airline’s passengers or flights in an APIS database does not mean that airline operated the cluster or suffered a compromise of its corporate network.

APIS data passes between airlines and government or border-control systems as part of international travel processing. Consequently, records from many carriers can be consolidated inside infrastructure controlled by another organization.

Singapore Airlines’ security team helped coordinate the response. It informed Kinryū Labs that relevant parties had been engaged and containment measures taken by June 8, but it did not provide a further statement.

Changi Airport Group investigated the issue but declined to comment. Vietnamese authorities had not responded before publication.

No evidence currently identifies the data controller, database administrator, or organization that provisioned the exposed Elasticsearch service. That gap complicates notification, forensic investigation, and decisions about responsibility for protecting affected travelers.

It also remains unknown whether the alternate access route belonged directly to the operator, a contractor, a cloud provider configuration, or another intermediary.

No ransom note or public sale was found, but theft remains possible

Kinryū Labs found no ransom note and no unfamiliar indices suggesting that a ransomware group had modified the cluster. Researchers also did not locate the dataset being advertised for sale online.

Those findings reduce the visible evidence of criminal exploitation, but they do not prove that the data remained untouched.

An attacker could have queried or exported information without adding indices, leaving a note, or advertising it publicly. Data may also be retained privately for espionage, targeted fraud, identity abuse, or later resale.

The researchers did not have the server logs needed to determine who accessed the cluster or whether bulk downloads occurred. As a result, the incident must be treated as an exposure with unresolved exfiltration risk rather than a confirmed theft.

Useful forensic evidence would include Elasticsearch audit logs, cloud access records, proxy logs, authentication events, network-flow data, and unusually large outbound transfers. Investigators would also need to identify access using the default credentials and requests made through the alternate cloud route.

No public indicators have been disclosed that would allow individuals to determine whether their own records were present.

Operators and travelers face different mitigation priorities

The immediate technical issue was remediated on June 8, but closing public access does not resolve the forensic and privacy consequences.

The responsible operator should preserve available evidence before rotating or rebuilding systems. It should then review every internet and cloud route leading to the cluster, replace default credentials, revoke associated tokens, and restrict Elasticsearch access through network allowlists and segmentation.

Defensive work should include:

• Auditing cloud gateways, proxies, tunnels, and alternate endpoints
• Enabling strong authentication and Elasticsearch audit logging
• Searching telemetry for bulk queries or exports
• Reviewing outbound data volumes for unexplained transfers
• Rotating credentials shared with connected systems
• Identifying the legal data controller
• Determining notification obligations across affected jurisdictions
• Assessing whether exposed passport identifiers require additional action

Travelers cannot patch the affected system themselves. They should instead be alert to messages that use genuine flight information to claim that a booking, baggage item, passport, visa, or refund requires urgent action.

Links and telephone numbers in such messages should be verified through the airline’s official website or application. Anyone who detects attempted misuse of passport details should contact the relevant passport-issuing authority and follow its guidance.

There is currently no established count of distinct affected people, no complete nationality distribution, and no confirmation that the records were downloaded. The database has been closed, but the central question—who may have accessed it before remediation—remains unanswered.