If you’ve flown to, from, or even just transited through Vietnam in the last few years, this one hits close to home. Researchers reported an exposed APIS (Advance Passenger Information System) Elasticsearch database with 220+ million passenger and crew records, sitting open because of chained misconfigurations and default credentials. The records span Jan 2017 to Apr 2026 . Nobody has confirmed if the data was copied, which is the worst kind of unknown: you can’t “undo” a passport number once it’s out in the wild .
What APIS data is (and why it’s so sensitive)
APIS stands for Advance Passenger Information System. In plain English: it’s the data airlines collect from you (and your passport) and send to governments before you arrive or depart. It’s used worldwide for border control and immigration checks, and it typically includes identity + travel details tied to a specific trip.
That last part is what makes APIS data feel so personal when it leaks. It’s not just “someone knows my name.” It’s “someone can see the exact itinerary that proved I was there, on that flight, on that day.”
What counts as “APIS data” in real life?
Think of APIS as a stitched-together snapshot that answers two questions at once:
- Who are you (as your government recognizes you)?
Your full name, date of birth, sex, nationality, passport/travel document number, document expiry date, and issuing country are common examples.
- How did you move through airports?
Your travel record can include flight number/date, airline, departure/destination/transit airports, seat assignment, baggage references, and scheduled/estimated/actual flight times.
So when people say “APIS leak,” it can mean passport details + flight details in one place. That combo is the danger.
Why APIS breaches are high-impact
APIS sits in a sweet spot for criminals because it’s:
- High-trust data: Passport numbers and official document details are treated as “proof” in a lot of processes.
- Perfect for targeted scams: Add flight numbers, airports, and dates, and a fake “airline support” message suddenly sounds real.
- Hard to take back: You can change a password. You can’t “change” where you flew, and replacing a passport isn’t a clean reset if copies are already out there.
APIS was never meant to be searchable on the public internet. It’s meant to be shared in controlled channels between airlines and border agencies. When it ends up exposed, it’s not just a privacy issue — it’s a blueprint of your identity and movement history sitting in one record.
What was exposed in this incident (fields + time window + what’s still unknown)
Here’s the part that matters if you’re trying to figure out, “Could this include me?”
Researchers reported an exposed APIS Elasticsearch cluster with 220,783,700 total entries: 210,318,069 passenger records and 10,465,631 crew records.
The records in that dataset reportedly span January 2017 through April 2026.
Scope: records, not “220 million people”
These are travel records, not a clean list of individuals. If you flew multiple times, your details could show up multiple times across trips.
That’s why this kind of exposure scales fast:
- One person who travels often can generate dozens of entries.
- Each entry can include both identity data and trip-specific data.
Exposed fields people actually care about
Based on what was reported, the exposed data included a mix of identity and itinerary details.
Identity / document data
- Full name
- Date of birth
- Sex
- Nationality
- Passport or travel document number
- Document expiration date
- Issuing country
Flight / itinerary data
- Flight number and date
- Airline
- Departure, destination, and transit airports
- Seat assignment
- Baggage references
- Scheduled, estimated, and actual flight times
If you’re wondering why this hits differently than a typical breach: it’s the pairing. A passport number alone is bad. A passport number plus where you flew, when you flew, and what seat you sat in is the kind of detail that can be used to impersonate, pressure, or convincingly scam someone.
What’s still unknown (and why that matters)
The worst gap: it’s unclear whether the database was copied or otherwise exploited before it was secured.
Researchers said they couldn’t conclusively determine exfiltration without server logs.
So you’re left with an uncomfortable reality: even if access is closed now, you can’t assume the risk is over if nobody can answer, “Was it downloaded?”
How researchers found it, and the remediation timeline (what happened in plain English)
The unsettling part isn’t just that an APIS database was reachable. It’s how easy a normal-looking setup can fail when a couple small mistakes stack up.
What happened (the “chain” in plain English)
Kinryū Labs said the Elasticsearch cluster was exposed through chained misconfigurations.
Here’s the simple version:
- The front door looked locked.
From the open internet, requests hit an endpoint that returned HTTP 401 “Unauthorized”, which would normally stop casual snooping.
- A side path got around that lock.
Researchers found a cloud-based path that led them to the cluster anyway.
- Once inside, the cluster accepted default credentials.
That’s the “are you kidding me” moment: the system reportedly accepted default login details, which meant the remaining barrier wasn’t much of a barrier at all.
If you’ve ever seen a building with a security guard up front but an unlatched service entrance in the back, this is the data version of that.
Timeline: discovery to containment
The reporting gives a clear sequence readers can anchor to:
- June 3: Kinryū Labs discovered the cluster while surveying exposed databases and began reporting it to Vietnamese authorities, impacted airlines, and national CERTs.
- June 8: Researchers said access was remediated (secured).
An authenticated email reviewed by BleepingComputer also indicates Singapore Airlines’ security team helped coordinate the response, stating it had engaged relevant parties and taken steps to contain the issue.
The extra detail that should bother everyone
Internet intelligence platform FOFA had recorded the host and port as far back as October 2022, and later identified it as a database in July 2023.
That doesn’t prove the passenger data was exposed the whole time, but it does show something in that neighborhood was detectable publicly for a while, and even the researchers couldn’t pin down when the data became retrievable through that second path.
What you should do next (practical steps, not panic)
If you take one thing from this: treat this like a high-quality identity leak with an annoying twist — it can power scams that sound uncomfortably specific. The exposed dataset reportedly included passport numbers plus itinerary details like flight numbers, airports, seat assignments, baggage references, and flight times , which is exactly the kind of context scammers use to get you to drop your guard.
1) Assume “itinerary-based phishing” is coming
Expect messages that quote real details and push urgency:
- “Your seat assignment changed, confirm here”
- “Your bag is delayed — enter details tied to your baggage reference”
- “Flight disruption — verify your passport info for rebooking”
How to handle it, every time:
- Don’t click links in unexpected airline/OTA emails or SMS.
- Open the airline app or type the official site yourself.
- If someone calls, hang up and call back via the official number on the airline’s website.
2) Lock down the accounts that attackers actually use
This isn’t about changing every password you’ve ever had. Focus on the accounts that help an attacker move money or impersonate you:
- Email account(s): change password, turn on MFA, and check for:
- new forwarding rules
- new “recovery email/phone”
- unfamiliar devices/sessions
- Airline and travel accounts (airlines/OTAs): reset passwords, enable MFA if offered, remove stored cards you don’t need.
- Banking + payment apps: enable transaction alerts and tighten transfer limits if your bank supports it.
3) Watch for identity fraud signals (lightweight, but consistent)
Because researchers said they couldn’t confirm if anyone copied the data without server logs , you’re operating with uncertainty. Your job is to catch downstream abuse early.
Keep an eye on:
- login alerts you didn’t trigger
- new accounts you didn’t open
- unexpected verification codes
- travel-related “support” emails you didn’t request
Also: document everything. Save emails, take screenshots, note dates/times. If this turns into an official dispute, a clean timeline helps.
4) Should you replace your passport?
A passport replacement can be reasonable in some cases, but it’s not a magic reset.
When replacement might make sense
- You’re seeing targeted fraud attempts that reference your passport or travel.
- You’re dealing with repeated account takeover attempts tied to your identity info.
- Your government’s passport authority advises replacement based on the incident.
When it usually doesn’t
- You’ve had no signs of misuse and no official recommendation.
- You’re treating replacement as a way to “erase” what happened (it doesn’t erase past exposure).
If you do nothing else, do the basics above and stay alert for scams that sound like they came from someone who’s seen your boarding pass.
What airlines, airports, and authorities need to change (to prevent APIS leaks like this)
This incident wasn’t some exotic, movie-style hack. It was basic security hygiene failing in a stack: a system that looked protected at one layer, a second access path that still reached it, and default credentials that should never exist in a production APIS environment.
Fix the failure points that made this possible
If you’re an airline, airport operator, government contractor, or anyone touching APIS/identity pipelines, the priorities are pretty clear:
- Kill default credentials, everywhere
- No vendor defaults. No “temporary” passwords that stick around.
- Tie this to deployment gates so systems can’t go live unless creds are rotated and verified.
- Remove public exposure paths (including “side doors”)
- In this case, direct access hit a 401 Unauthorized, but a cloud-based path still led to the cluster. That’s a network design and cloud routing problem, not a user behavior problem.
- Treat APIS stores like crown jewels: private networks, strict allowlists, and no “reachable from anywhere” endpoints.
- Continuous external exposure monitoring
- FOFA recorded the host/port back in October 2022 and identified it as a database in July 2023. That’s exactly what external monitoring is meant to catch early.
- Don’t rely on “we think it’s private.” Verify it from the outside, continuously.
- Real logging, so “was it downloaded?” isn’t a mystery
- Researchers couldn’t confirm whether data was copied without server logs. That’s an operational failure with real consequences for passengers because it blocks clean incident response.
- You need logs that can answer: who accessed what, from where, and how much.
What you can control as a traveler (reduce linkability)
Even when you can’t control how APIS data is handled upstream, you can control how easily a breach ties back to your everyday identity.
A practical move: separate your travel accounts from your primary email/phone. That way, if a travel system leaks, it doesn’t automatically hand over the contact details tied to your bank logins, social accounts, and personal inbox.
If you want an easy way to do that, tools like Cloaked let you create masked emails and phone numbers for airline and OTA accounts. It’s not a fix for an APIS leak, but it can reduce the blast radius when breaches spill into the phishing and account-takeover phase.
