On 3 June 2026, while surveying exposed databases during ransomware research, Kinryū Labs found an Elasticsearch cluster holding Advance Passenger Information.

APIS is the data airlines are required to send to a government before passengers and crew arrive or depart. Not data you agreed to share — data your airline is obliged to hand over so that you can be permitted to fly.

The cluster held 210,318,069 passenger records and 10,465,631 crew records across 29 indices, about 107 GB, spanning January 2017 to April 2026.

The number first, because it will be misused

220,783,700 is a count of travel records, not of people.

One person who flew twelve times is twelve records. A crew member is a record per rotation. Nobody has published a distinct-person figure and it would be far smaller than the headline, though still very large.

Kinryū Labs says this plainly. It will be dropped within a news cycle, and "220 million travellers exposed" is the sentence that will circulate instead.

What was in each record

Names, dates of birth, sex, nationalities. Passport or travel-document numbers with expiry dates and issuing countries. Flight numbers and dates, airline, departure, destination and transit airports, seat assignments, baggage references, and scheduled, estimated and actual times.

That is a complete identity document plus a nine-year movement history. It is the same category of harm as the licence scans sold through Nexus last week — a government-issued number you cannot rotate, attached to a person who never chose the system holding it.

The travel history is the part that is different, and worse in a specific way. Where somebody was, on which date, sitting next to whom, is not identity theft material. It is targeting material.

It was not an open Elasticsearch

This is the detail that separates it from the usual story, and it deserves care.

The endpoint returned HTTP 401 Unauthorized when accessed directly. The front door was locked.

The researchers reached the data through a cloud-based path using default credentials.

So the failure was not somebody putting a database on the internet with no password. It was a second route to the same data, secured with credentials that shipped in the box. That is a much more common failure and a much harder one to find, because every external scan of the primary endpoint comes back clean.

Nobody has established when that second path became reachable.

Whose it is, and who answered

The cluster was hosted in Viettel-assigned IP space in Hanoi, which points to Vietnamese operation. Which Vietnamese organisation ran it has not been confirmed — BleepingComputer could not establish it.

Vietnamese authorities were contacted in advance and did not respond.

Singapore Airlines coordinated the response. Changi Airport Group investigated and declined to comment. Access was remediated on 8 June, five days after discovery.

Read that list again. The data is passenger information collected under one government's border requirements, and the people who actually did something about it were an airline and an airport in a different country.

Whether anyone took it is unknowable

No ransom notes. No suspicious indices. No sign of tampering.

Also no server logs, which means Kinryū Labs could not determine whether anyone had copied the data, and neither can anybody else. "No evidence of exfiltration" here means "no evidence either way", and those are very different sentences that get printed identically.

What to do

This is another section where honesty means admitting individuals have almost nothing.

  • You cannot check whether you are in it, and no notification scheme covers this. APIS data has no consumer-facing controller to ask.
  • A passport number is not a secret you can change on demand. If yours is close to expiry, renewing rotates the number — that is the only lever, and it is a slow and expensive one.
  • Be alert to travel-themed phishing that knows your itinerary. A message quoting a real past flight, seat and date is far more convincing than the usual attempt, and this dataset supports exactly that.
  • If you operate an Elasticsearch cluster, enumerate every path to it, not just the one your scanner tests. The front door here was fine.
  • Change default credentials on management and cloud access paths. That is the actual finding, under the headline number.

What is not established

  • Which organisation operated the cluster. Not confirmed.
  • How many distinct people are represented. Only the record count is published.
  • When the second access path became exploitable.
  • Whether the data was copied, sold or ransomed. No logs survive to say.
  • Whether Vietnamese authorities have taken any action. No response was received.