Amadeus Airline Data Breach: What QA Should Test in Third-Party Integrations

Photo: ノボホショコロトソ — “Narita Airport Terminal 2 Check-in Area 01”, CC BY 4.0, via Wikimedia Commons.

You pick an airline. You never pick the reservation platform sitting behind the booking confirmation email. This week that gap mattered. A vulnerability in a travel-tech provider’s booking-display environment exposed passenger details for several major Asian carriers — and the same pattern showed up elsewhere in hosting tools and analytics stacks. For QA, the question is not “did security miss a CVE?” It is: what should we have tested in third-party integrations before the vendor became the blast radius?

This Friday breakdown covers the Amadeus airline incident, the DreamHost File Manager credential leak, and a critical Metabase password-reset flaw — then turns them into a practical checklist. New here? Start Here. Related: our notes on the LiteLLM supply-chain attack and the evergreen Security Testing for QA Engineers guide.

What happened with Amadeus (facts only)

According to The Record (4 Nov 2026), Japan Airlines, Cathay Pacific, Korean Air, Asiana Airlines, Singapore Airlines and Malaysia Airlines disclosed customer data exposure tied to Amadeus IT Group — a Spanish travel-tech company that builds reservation, ticketing and check-in platforms used widely across aviation.

An Amadeus spokesperson told The Record the company became aware of a vulnerability affecting a travel booking display environment. Certain booking-display data was accessible. Amadeus said there was no evidence payment or financial data was accessed, and no indications of ransomware. It said the vulnerability was fixed and monitoring was strengthened.

• Japan Airlines: about 92,000 customers affected.
• Cathay Pacific: about 53,000 records — booking numbers, passenger names, flight details; some records included passport/travel-document data, frequent-flyer numbers and email addresses.
• Singapore Airlines: about 46,000 records — confirmation numbers, itineraries and names; the airline said it would contact passengers with upcoming flights to change exposed booking numbers and warned about malicious follow-up email.
• Korean Air, Asiana, Malaysia Airlines: also notified customers of potential exposure linked to the same provider incident.

Cathay reported Amadeus said threat actors used login credentials assigned to its system account. Every airline stressed that its own systems and operations were unaffected — the leak lived in the shared vendor surface. Kaseya’s Week in Breach News (4 Nov 2026) framed the same story as a travel-tech supply-chain hit with the same core lesson: passenger PII can leave through a partner you never chose.

Why third-party risk is a QA problem

Security owns vendor assessments. Product owns the booking flow. QA sits where those meet the user: the confirmation screen, the “manage booking” link, the SSO hop into a partner portal, the webhook that syncs PNR data into your CRM.

If your test plan only covers “happy path on our domain,” you miss the failure modes that made this week expensive:

• Shared credentials and system accounts that outlive the project that created them.
• Display / read-only environments that still hold full passenger records.
• Data-minimisation gaps — a booking lookup returns passport fields when a confirmation number would do.
• Customer messaging after a vendor incident — booking numbers that must rotate, phishing that reuses real itineraries.

That is the same family of lesson as LiteLLM and other dependency breaches: the package or platform you integrate becomes part of your attack surface the moment it touches production PII.

DreamHost: credentials and sessions as a parallel lesson

On the hosting side, BleepingComputer reported DreamHost’s confirmation that attackers accessed its web File Manager at files.dreamhost.com. DreamHost’s own October Security Incident notice says the window ran roughly from August 2026 through 23 October 2026. Exposed: FTP/SFTP usernames and passwords of users who logged into File Manager in that window, plus some webmail session information. DreamHost said it found no evidence of control-panel or billing access.

Advice to customers (and a clean QA mirror) was practical hygiene: review site files for unexpected changes, check webmail forwarding and filters, rotate reused passwords, update saved FTP/SFTP clients. If you have ever tested “reset password email works,” you should also test “unknown filter or forward is visible and alerted” — the quiet persistence path after a session or credential leak. Pair that with our Wednesday how-to on how to check if your email or password was leaked.

Metabase: password-reset surfaces and unexpected fields

Singapore’s Cyber Security Agency renewed an active-exploitation warning on 4 Nov 2026 for CVE-2026-72898 — a critical issue in Metabase that can let an unauthenticated attacker abuse the password-reset path to gain administrator access on affected instances. Metabase’s own high-level write-up of the August 2026 incident is at their “What happened?” post. We will not walk through exploit mechanics here — only defensive hygiene and what QA should verify.

Patch immediately to (or newer than) the fixed lines CSA lists: 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5, and the matching Enterprise 1.x builds. Temporary workaround if you cannot upgrade yet: block access to /api/session/reset_password. After upgrading a publicly reachable instance, follow post-upgrade guidance: revoke active sessions, review admin accounts and API keys, rotate credentials for connected databases, and check logs for unusual access.

For QA, the transferable lesson is about closed request contracts. Password-reset and other “unauthenticated but sensitive” endpoints should reject unexpected body fields, never pass a raw request object into auth or ORM layers, and fail closed when schemas do not match. Add regression cases for “extra keys present,” “session invalidated after credential change,” and “API key creation triggers an alert.”

Checklist: what QA should test in third-party integrations

Run these only on systems you own or are explicitly authorised to test. Treat vendor staging the same as production when it holds real or production-like PII.

1. Inventory every vendor that can see PII. Booking engines, File Managers, BI tools, CDNs, support desks, email relays. Name the data classes each one stores or displays.
2. Prove data minimisation on read APIs. A “display booking” call should not return passport numbers or full contact dumps unless the journey truly needs them. Assert field allow-lists in contract tests.
3. Hunt shared / system accounts. No long-lived “integration” passwords shared across environments. Prefer short-lived tokens, scoped roles, and rotation on offboarding.
4. Test partner SSO and portal auth like first-party login. Broken object-level auth, missing step-up on bulk export, and “read any record after one soft login” are the Korea-bank / partner-portal class of bug — same theme, different industry.
5. Session and credential blast radius. After password reset or suspected leak: other sessions die, API keys can be listed and revoked, forwarding/filters are reviewable. DreamHost’s advice maps 1:1 onto product test cases.
6. Closed schemas on sensitive endpoints. Especially password-reset, magic-link, and token-exchange routes: unexpected fields must 400; never silently ignored into ORM filters.
7. Vendor incident runbook drill. Can you rotate booking references, force re-auth, and message customers without waiting for the vendor’s PR post? Singapore Airlines’ booking-number change is the kind of customer-facing control your playbook should already name.
8. Phishing follow-on. Leaked names + itineraries + emails fuel convincing scams. Verify support scripts and in-product warnings after a vendor notice. (See also the leak-check post linked above.)
9. Dependency and SaaS version gates. Metabase-style CVEs: CI or ops must fail a deploy if a critical component is below the patched floor, and publicly exposed admin tools need an explicit network policy.
10. Logging that survives the vendor. You need enough of your own audit trail to answer “who queried which passenger / which file / which dashboard” even when the partner’s logs are incomplete.

FAQ

Did Amadeus say payment cards were stolen?

No. Amadeus told The Record there was no evidence payment or financial data was accessed, and no ransomware indicators. Airlines still treated passenger identity and booking data as serious exposure — and so should your risk model.

Our airline / booking vendor is different. Does this still apply?

Yes. The failure mode is “third party holds displayable PII behind a shared or weakly scoped login,” not the Amadeus brand specifically. Swap in your GDS, PSS, hotel CRS, or support SaaS and the checklist still holds.

We only use Metabase internally. Are we fine?

Internal does not mean safe if the instance is reachable from the internet or from a broad corporate VLAN. CSA’s warning stresses publicly accessible self-hosted instances. Patch, restrict the reset endpoint if needed, then revoke sessions and rotate DB credentials.

What should individuals do after the airline notices?

Read the airline email carefully (watch for lookalikes), change exposed booking references if offered, treat unexpected “rebook / refund / upgrade” messages as phishing, and check whether any reused passwords appear in breach lookups.

Short close

This week’s biggest cyber story was not a clever new exploit class. It was familiar third-party gravity: a booking-display environment, a File Manager plugin surface, a password-reset contract that was not closed. QA cannot vendor-manage the whole internet — but QA can refuse to ship integrations that over-fetch PII, share eternal credentials, or leave sensitive endpoints untested against unexpected input.

Pick one vendor integration this sprint and run the checklist against it. Then subscribe so next Friday’s breakdown lands in your inbox: Start Here · follow.it/hackup-s.