Vietnam-Linked “pax-info” Leak Exposed 220.8 Million Airline Travel Records

An exposed travel-data system can be dangerous even when it contains no passwords. Reporting says Kinryū Labs found a Vietnam-linked Elasticsearch cluster called pax-info on June 3, 2026, containing 220.8 million Advance Passenger Information System (APIS) records. The cluster was reportedly reachable through an alternate cloud-based path and accepted default credentials. 259

What happened

The reported database held 220,783,700 records in 29 indices totaling roughly 107 GB: 210,318,069 passenger entries and 10,465,631 crew entries. Those are records, not necessarily unique people; frequent travelers and crew may appear multiple times. The data covered travel from January 2017 through April 2026. 9

APIS data is used to transmit passenger and crew identity and flight details before international travel. The records reportedly related to people traveling to, from, or through Vietnam, meaning exposure was not limited to Vietnamese citizens. 212

What data was exposed

Reported fields included:

• Full names, dates of birth, sex, and nationality
• Passport or travel-document numbers, issuing countries, and expiration dates
• Flight numbers and dates, airline information, and departure, destination, and transit airports
• Seat numbers, passenger or crew status, baggage references, and scheduled, estimated, and actual travel timing 617

That combination is more sensitive than a basic contact-data leak. A passport number and date of birth can help an attacker impersonate an airline or travel authority; real route, flight, seat, and timing details can make a scam unusually convincing.

How the cluster was exposed

Accounts of the discovery describe a chain of security failures rather than an intrusion into a traveler’s account. The Elasticsearch cluster was reportedly not directly accessible from the public internet, but an alternate cloud-based route allowed access. Once on that path, researchers found that default credentials were accepted. 5

Kinryū Labs reportedly encountered the cluster while surveying exposed databases during ransomware-related research. The data was later reported as locked down or no longer accessible. 25

However, public reporting does not conclusively identify the database operator, the precise cloud provider, the data controller, or the source systems that supplied the records. A server’s Vietnam-associated network location is not proof that a particular Vietnamese airline, airport, border authority, or government agency owned the database. 46

Who may have been affected

The available reporting supports a broad but limited conclusion: the data appears to cover international passengers and crew who traveled to, from, or transited through Vietnam during the nine-year period. 212

It does not establish:

• A complete nationality or country-by-country breakdown
• A verified list of affected airlines
• A definitive count of unique individuals
• Which organizations supplied, controlled, or processed the data

It would therefore be premature to identify a named carrier or authority as responsible solely because an airline code or flight might have appeared in the records.

Was the data stolen or misused?

The exposure meant an unauthorized party could potentially have viewed or copied the records while the cluster was reachable. That alone is a serious confidentiality failure.

But public reports cited here do not provide evidence of a confirmed malicious download, sale on criminal forums, ransomware event, or passport fraud tied specifically to this database. 5 There is also no public, independently auditable account of how long the cluster was exposed, whether access logs could identify visitors, or whether every record was current and authentic.

The correct conclusion is cautious: there is no reported proof of theft, but neither is there proof that copying never occurred.

Why the exposure creates fraud risk without passwords

No passwords were reported in the exposed fields, which reduces the immediate risk of direct password resets or straightforward credential-stuffing attacks. Yet the dataset remains highly valuable for social engineering.

A criminal with a person’s name, passport details, flight number, route, seat, baggage reference, and travel time could plausibly send a fake:

• Flight-change or cancellation notice
• Baggage-fee or compensation request
• Visa or immigration “verification” message
• Airline loyalty-account alert
• Request to reconfirm passport details before travel

Travel timing also raises privacy concerns. It can reveal when someone was expected to be in transit or away from home, creating particular risks for crew members, frequent travelers, and people at heightened personal-security risk.

Practical steps for travelers

If you traveled to, from, or through Vietnam between January 2017 and April 2026, treat unsolicited travel messages with added caution.

1. Do not use links in unexpected airline, baggage, visa, or immigration messages. Open the airline or authority’s official app or type its known web address yourself.
2. Verify schedule changes independently. Check the booking through the airline’s official channels before paying a fee or sharing passport information.
3. Protect airline loyalty accounts. Use a unique password and enable multi-factor authentication where available.
4. Be wary of requests for passport scans or “confirmation” of document details. Contact the airline, travel agency, or government authority through a verified contact method instead.
5. Keep an eye on travel-document anomalies. If you suspect passport misuse or identity fraud, contact the relevant passport issuer or local authority.

Regulatory implications remain dependent on ownership and jurisdiction

Responsibility cannot be assigned from the available reporting because the operator and relevant processing roles remain unverified.

Under Vietnam’s Decree 13/2023/ND-CP, a personal data controller or controller-processor that detects a violation of personal-data-protection rules must notify the Ministry of Public Security’s cybersecurity authority within 72 hours, with reasons required for late notification. Whether and how that applies here depends on the responsible entity and facts not yet public. 2933

GDPR obligations could also arise if a relevant controller or processor falls within the regulation’s territorial scope. Article 33 generally requires a controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach, unless the breach is unlikely to pose a risk to individuals’ rights and freedoms. 43

For now, the central facts are clear: a large repository of passport-linked travel records was reportedly exposed by preventable access-control failures. The unanswered questions—who operated it, who accessed it, and whether data was copied—remain as important as the record count itself.