The Amadeus airline breach: one vendor account, three years of bookings, a dozen airlines

Short answer. Someone used login credentials assigned to a system account at Amadeus, the reservation technology provider behind hundreds of airlines, to view passenger booking records. The airlines that have disclosed so far put the access window at roughly August 2023 to September 2026, and Japan Airlines, ANA and Thai Airways give the exact dates as 10 August 2023 to 23 September 2026. Japan Airlines reported about 92,000 affected customers, ANA about 37,800, Cathay Pacific about 53,000 bookings, Singapore Airlines about 46,000 booking records, Thai Airways about 60,529 passenger records, and Finnair about 116,000 bookings on flight lists that were reached, of which about 750 were opened. For most people the data was a name, a booking reference, flight dates, route and cabin class. For a smaller group in each airline it also included email, phone, passport number, nationality and frequent flyer number. Every airline says its own systems were not breached, and Amadeus says there is no evidence that payment or financial data was accessed.

The airlines did nothing unusual. They put their passengers' bookings where the whole industry puts them, in a shared platform run by a specialist vendor. That is the uncomfortable lesson, and it applies far beyond aviation. If a vendor holds your customers' records, the vendor's account hygiene is your breach risk, and the vendor's notification speed is your notification speed.

This post sets out what each airline has said, keeps confirmed facts apart from reported ones, explains why a booking reference matters more than it looks, gives passengers a practical checklist, and then turns to the part that applies to every company: how to manage the risk of a platform vendor that holds data for you and for hundreds of your competitors at the same time. If you only have ten minutes, read "What passengers should do" and "Fix it without waiting for upstream".

We covered the first two disclosures, Korean Air and Asiana, together with a separate Amadeus exposure reported by heise online, in our 26 October post. This post picks up from there, with the wave of airline notices that followed.

At a glance

What each airline has disclosed

The airlines did not publish at the same time, and they did not count the same thing. Some count customers, some count bookings, some count records, and Finnair counts bookings that sat on flight lists the intruder reached. Adding the figures together produces a number that means nothing. Read each one in its own unit.

Japan Airlines and Japan Transocean Air

JAL said Amadeus informed it on 23 October and published its notice on 28 October. According to Japan Cyber Watch's summary of the JAL notice, about 92,000 passengers' booking records were viewed. About 90,000 involved only basic booking data: booking number, name, flight date, route and cabin class. About 2,000 also included email address, phone number, passport number, nationality, frequent flyer number, airline, flight number, ticket number and seat number. JAL said card numbers and passwords were not involved and that no misuse had been confirmed. Access traces run from 10 August 2023 to 23 September 2026.

ANA

ANA announced on 30 October that about 37,800 customers were affected, as reported by Aviation Wire. About 36,100 had five items viewed: name, booking reference, travel date, route and cabin class. About 1,700 also had email, phone, passport number, nationality, mileage number, airline, flight number, ticket number and seat number viewed. The window covers bookings from 10 August 2023 to 23 September 2026.

ANA's timeline is the most detailed public account of how the notification unfolded. Amadeus detected the unauthorized access on 24 September. ANA says it received no report that day. On 16 October ANA learned that other airlines using Amadeus had confirmed unauthorized access and started checking its own bookings. Amadeus reported the incident to ANA on 20 October. Amadeus told ANA the credentials involved had been invalidated and monitoring strengthened, and that there was no evidence of ransomware, data alteration or deletion. ANA reported to Japan's Personal Information Protection Commission and warned customers about fake emails, calls, websites and social media ads impersonating the ANA Group.

One more detail matters for the risk picture. ANA has used Amadeus for international flights since April 2015 and moved its domestic flights onto it in May 2026, according to Japan Cyber Watch. A platform migration expands what a vendor holds overnight. It is a natural moment to revisit what the vendor's access controls look like.

Cathay Pacific

Cathay published its notice on 30 October. About 53,000 bookings were affected by "unauthorized access to reservation data held by Amadeus IT Group", per AeroCorner's report of the notice and Cathay's own page. Most cases involved booking references, passenger names and flight details. A smaller subset potentially included email and phone contacts, travel document details or frequent flyer numbers. Cathay said an unauthorized party used "login credentials assigned to a system account at Amadeus". Amadeus told Cathay on 28 October and sent further details on 29 October. Cathay said there was no evidence that financial or payment information was accessed. Hong Kong's privacy commissioner received Cathay's notification and opened an investigation, according to the same report.

Malaysia Airlines

Malaysia Airlines said on 31 October that "certain customer information processed through Amadeus between August 2023 and September 2026 may have been affected", as paraphrased by the New Straits Times. It gave no count, said its own IT systems were not compromised and said there was no evidence financial information was accessed.

Singapore Airlines

SIA said on 3 November that about 46,000 booking records held by Amadeus may have been affected, as reported by VnExpress and Reuters-based reports in The Star. The data included customer names, booking reference numbers, itineraries and booking classes. For about 620 records, email addresses, phone numbers, travel document details and KrisFlyer numbers may also have been accessed. SIA said Amadeus confirmed that no bank account or card information was exposed and no bookings were changed. SIA is contacting customers with upcoming travel so they can change their booking references, and Singapore's Personal Data Protection Commission said on 4 November that it was investigating.

This is SIA's third third-party data incident since February 2021, according to the VnExpress report citing The Straits Times. The 2021 incident at SITA, another aviation IT provider, affected 580,000 KrisFlyer and PPS members. The 2022 incident at its in-flight retailer KrisShop exposed data of 4,749 customers. None of the three began inside SIA's own systems.

Thai Airways

Thai Airways issued its statement on 9 November. Amadeus notified it of unauthorized access to booking data held in Amadeus systems between 10 August 2023 and 23 September 2026. Initial checks point to about 60,529 passenger records, with about 376 further records that may have been affected, according to Nation Thailand. The core fields were names, booking references, travel dates, routes and cabin classes. The wider set may include contact details, passport numbers, nationalities and frequent flyer numbers. Thai said passengers' card information was unaffected, its own systems and operations were not affected, and it had notified the relevant regulators. It also said Amadeus revoked the login credentials used, reset all affected passwords and strengthened monitoring. Thai will contact affected passengers individually once its checks are complete.

Finnair

Finnair's figure needs the most careful reading. Amadeus told Finnair that flight lists from several airlines had been accessed, including about 116,000 Finnair bookings, and that about 750 of those bookings had been opened for examination, 30 of them tour packages from the group's tour operator Aurinkomatkat, according to Aviacionline's 9 November report. Finnair assigned new booking codes to the opened bookings that are still active, said its own systems were not breached, contacted Finland's National Cyber Security Centre and said it would email customers whose contact details Amadeus provided. Finnair's CISO, Timo Arndal, was quoted as saying, "We are demanding a detailed clarification from Amadeus on this incident."

The same report says Finnair described Amadeus as the data controller for this processing, said Amadeus had notified an EU data protection authority under GDPR, and pointed passengers to dataprotection@amadeus.com. That framing is worth noting, because in most vendor relationships the airline is the controller and the vendor the processor. We return to why it matters below.

SAS, Norwegian and Qantas

Sweden's Realtid reported on 10 November that SAS told the Swedish data protection authority, IMY, that data on 350,164 SAS travelers may have been exposed, mostly booking numbers, travel dates, flight information and passenger counts for older bookings and completed trips. SAS assessed the risk as not high and decided not to inform the people concerned, while saying it may revisit that if new information emerges. Realtid also reported that Norway's National Security Authority (NSM) believes intruders may have had access for at least three years and that the gap was closed on 23 September 2026. We have not been able to open NSM's statement directly, so treat the NSM details as reported.

Norwegian has reported the incident to Norway's data protection authority but has not published a count, according to German trade press. Qantas said Amadeus told it of "unauthorised access" to one of its systems, contained in September, and that it was working to "understand the impact to any Qantas bookings", with "no impact to Qantas systems or databases", per Information Age. Qantas notified the Australian Cyber Security Centre.

Korean Air and Asiana

Amadeus notified Korean Air and Asiana on 20 October, and both disclosed on 23 October. Asiana said the cause was unauthorized access using "login credentials assigned to an account" in Amadeus's system and that the incident occurred in Amadeus's managed area. Neither published a count. Our 26 October post covers both in detail.

Timeline

Dates are taken from the airline notices and the reports linked above. Where only one source carries a date, it is marked as reported.

• 10 August 2023. Earliest access traces in the JAL, ANA and Thai notices.
• 21 September 2026. Amadeus says it was made aware of a "potential vulnerability" that "affected a display environment for travel bookings", as it told heise online.
• 23 September 2026. Last access traces in the JAL, ANA and Thai notices. Realtid reports NSM said the gap was closed this day.
• 24 September 2026. Amadeus detects the unauthorized access, according to ANA.
• October 2026. Amadeus publishes a statement on a vulnerability in a travel booking display environment, saying certain booking-display data was accessible, there is no evidence payment or financial data was accessed, and there are "no indications that this vulnerability has been exploited for ransomware purposes."
• 13 October. heise online reports an unauthenticated Spring Boot heap dump in an Amadeus display environment that contained credentials and tokens, with Lufthansa and Condor passenger records visible.
• 16 October. ANA learns that other Amadeus airlines have confirmed unauthorized access.
• 20 October. Amadeus notifies Korean Air, Asiana and ANA.
• 23 October. Korean Air and Asiana disclose. Amadeus notifies JAL.
• 28 October. JAL discloses about 92,000 customers. Amadeus notifies Cathay.
• 30 October. Cathay discloses about 53,000 bookings. ANA discloses about 37,800 customers.
• 31 October. Malaysia Airlines says customer data may be affected.
• 3 and 4 November. SIA discloses about 46,000 booking records; Singapore's PDPC says it is investigating. Qantas says it is assessing exposure.
• 9 November. Thai Airways discloses about 60,529 records. Finnair discloses about 116,000 bookings on affected flight lists, about 750 opened.
• 10 November. Realtid reports the SAS notification to IMY covering 350,164 travelers.

Two gaps stand out. From detection on 24 September to the first airline notifications on 20 October is 26 days. To Cathay's notification on 28 October is 34 days. Passengers who had upcoming flights spent that month with booking references that someone else had seen.

Is this the same incident heise reported?

We do not know, and none of the public sources say. What can be placed side by side is this. Amadeus's public statement and its comment to heise both describe a vulnerability in a "display environment" for travel bookings, which Amadeus says it learned of on 21 September. heise reported that the exposure in that environment was a heap dump containing credentials, tokens and administrator passwords. The airlines describe misuse of login credentials assigned to an Amadeus system account, with access ending on 23 September and detection on 24 September. Several airline notices say Amadeus reset passwords and revoked credentials as part of the fix.

The overlap in dates is close. It is still only an overlap. No source has said the heap dump held the credentials used against the airlines' booking data, and no source has said it did not. We will update this post if Amadeus or an investigating authority says more.

What was exposed, and why a booking reference matters

Most of the records contain a name, a booking reference, a date, a route and a cabin class. That can look harmless. It is not, for three reasons.

The booking reference is a credential. The six-character locator printed on every itinerary and boarding pass is, together with a surname, enough to open "manage booking" on most airline websites. From there a person can often see contact details, change seats, add or change meal requests, and on some carriers change flights or request refunds to the original payment method. TechCrunch reported in 2019 on a researcher who showed that some airline websites using Amadeus let anyone edit a reservation with only the booking reference, and that references could be guessed because the system did not limit request rates. That is why SIA and Finnair are reissuing references for upcoming trips. A changed reference turns the stolen one into noise.

Travel data makes phishing convincing. A message that says "Your flight SQ 322 to London on 14 December has been rescheduled, please confirm here" and gets the flight number, date, cabin and your name right is far more convincing than generic spam. Francis Fong, honorary president of the Hong Kong Information Technology Federation, advised checking any airline-branded message through the airline's own app or website rather than its link, even when the details are accurate, as AeroCorner reported. JAL and ANA have already flagged fake websites, and ANA has warned of social media ads impersonating its group.

The smaller subset is the real risk. For about 2,000 JAL customers, about 1,700 ANA customers, about 620 SIA records, about 376 Thai records and an unpublished share at Cathay, the exposed fields include passport number, nationality, email, phone and frequent flyer number. Passport number plus name plus nationality is a strong input for identity fraud in many countries, and frequent flyer accounts hold points that are routinely stolen and resold. Norway's data protection authority warned that leaked travel data can be used for fraud and identity theft, according to Realtid.

There is also a quieter category: travel patterns. Three years of who flew where, when and in which cabin is sensitive for executives, journalists, people under protection orders and anyone whose movements are their own business. NSM reportedly asked affected organizations to assess risks to employees, change logins on travel agency portals and review future bookings made before 23 September.

What passengers should do

If you flew with or booked on any of the airlines named above between August 2023 and September 2026, these steps are worth ten minutes, whether or not you have received a notice.

1. Treat every airline message as suspect for the next few months. Do not click links in emails, texts or ads about your booking, refunds, compensation or "verification". Open the airline's app or type its address yourself.
2. Check upcoming bookings. Log in through the airline's own site and confirm the flight, seats, contact email and phone are what you set. If the airline offers a new booking reference, accept it.
3. Secure your frequent flyer account. Change the password to a unique one, turn on any second factor the program offers, and check recent activity for redemptions or profile changes you did not make.
4. Know what a genuine notice looks like. Airlines say they will contact affected customers individually. A genuine notice will not ask for your password, card number or a payment. Cathay, Thai and ANA all say they will contact people directly once checks are complete.
5. If your passport details may be in the subset, watch for identity fraud in the usual places: unexpected credit applications, account openings or correspondence in your name. In some countries you can place a fraud alert or credit freeze. Replacing a passport is rarely needed for this kind of exposure, but ask your passport authority if you have a specific reason to be concerned.
6. Stop posting boarding passes. The barcode on a boarding pass encodes the booking reference. It is the same credential this incident exposed.
7. Ask, if you need to. Airlines have set up contact points in their notices. Finnair directed passengers to Amadeus at dataprotection@amadeus.com for questions about Amadeus's processing, according to Aviacionline.

Corporate travel managers have a slightly longer list: confirm with your travel management company whether its Amadeus office IDs or portal logins were involved, change those logins, review bookings made before 23 September for upcoming trips, and brief travelling staff on the phishing risk.

Why this keeps happening in airline IT

The airline does not hold the booking

When you book a flight, the record is usually created and stored in a passenger service system or global distribution system run by a vendor. A small number of providers serve most of the world's airlines. The airline, the travel agency, the airport handler and the codeshare partner all read and write the same record, each through their own access. That shared record is what makes interlining, codeshares and agency sales work. It also means the airline's customer data lives in a system the airline does not operate, under credentials the airline does not issue.

Shared platforms concentrate risk

One credential at the platform reached records from at least a dozen airlines across Asia, Europe and Australia. No single airline could have prevented that with its own controls, because the access did not pass through any airline's systems. This is what concentration risk looks like in practice. The airline's security program can be excellent and still not reach the place where the incident happened.

System accounts are the soft spot

The phrase every notice repeats is "login credentials assigned to a system account". A system account, or service account, is a non-human login used by software, integrations or operational tooling. These accounts often have broad read access, long-lived passwords, no second factor (because there is no human to complete one) and less monitoring than human logins. They are created for a project and forgotten when the project ends. A credential that lasts three years without anyone noticing it being used from the wrong place is the signature of a system account without behavioral monitoring.

Fourth parties are invisible by default

For a corporate traveler, the chain often runs: employer, travel management company, airline, Amadeus. For the airline, Amadeus is a third party, and the vendors Amadeus relies on are fourth parties. Heise's report that the exposed environment contained hundreds of German travel agency office IDs shows how many organizations sit around one platform. Few third-party risk programs reach past the first link, and almost none know which of their vendors share a platform with which others.

The business side: notification clocks run on the vendor's timing

Every privacy regime in the affected countries puts the duty to notify on the organization that controls the data, usually within days. Thailand's PDPA and the GDPR set 72 hours for notifying the regulator once the controller becomes aware. Singapore's PDPA requires notifying the PDPC within three calendar days of assessing that a breach is notifiable. Japan's APPI requires a prompt preliminary report to the PPC and a final report within 30 days, or 60 days where the breach was caused by an unauthorized act.

Those clocks start when the controller becomes aware. For the airlines that meant 20 October, 23 October or 28 October, not 24 September. That is legally defensible for the airline. It is not good for the passenger. A processor is required under GDPR Article 33(2) to notify the controller "without undue delay" after becoming aware of a breach. Whether 26 to 34 days meets that standard will be for regulators to decide, and several of them now have the case.

Finnair's statement that Amadeus is the data controller adds a further wrinkle. If the vendor is a controller in its own right for some processing, the vendor notifies the regulator and the affected people, and the airline depends on the vendor's judgment about scope and risk. SAS, by contrast, assessed the risk itself and chose not to notify. Two airlines, one incident, two different answers to the question "who tells the passenger?" Contracts should settle that before an incident, not during one.

There is also reputation. Customers do not distinguish between an airline and its reservation vendor. Finnair's CISO demanding "a detailed clarification from Amadeus" in public is a sign of how much the airline is carrying for an incident it did not cause.

Fix it without waiting for upstream

None of the following needs Amadeus, or any vendor, to do anything first. The steps are grouped by who does them. Most apply to any company that hands customer data to a platform vendor, whether that is a reservation system, a CRM, a payments processor, a helpdesk or a marketing tool.

Airlines and travel companies affected now

1. Rotate booking references for future travel. Reissue the locator for every affected booking with a departure date ahead, as SIA and Finnair are doing. Prioritize the subset with passport and contact data.
2. Raise friction on manage-booking flows. For affected bookings, require an extra check (a one-time code to the email on file, or the frequent flyer login) before contact details, refunds or flight changes can be made. Rate-limit lookups by booking reference and surname.
3. Watch for the phishing wave. Register lookalike domains you can find, ask your email provider and registrars for takedown routes, publish a clear "how we will contact you" page, and give contact center staff a script for passengers who call about suspicious messages.
4. Lock down frequent flyer accounts in the subset. Force a password reset, flag redemptions and profile changes for review, and require a second factor where your program supports it.
5. Ask the vendor for specifics in writing. Which records were viewed, by which account, from which addresses, on which dates, and what indicators of compromise can you share. Ask for the account's full audit log for your data, not a summary.
6. Review your own access into the vendor. List every login your staff, agencies and integrations hold in the vendor's platform. Rotate them, remove the unused ones and enable every second factor and IP restriction the platform offers.

Any company that shares data with a platform vendor

1. Build a data-at-vendor register. For each vendor, record what customer data it holds, how much, for how long, under which role (processor or controller), and which of your systems and staff hold credentials into it. Most companies know their vendor list. Few know what each vendor actually holds.
2. Minimize what you send and how long it stays. Passport and identity data is often collected for a single purpose, like advance passenger information, and kept for years afterward. Ask each vendor what its retention is for your data and whether it can purge completed records sooner. Data that no longer exists cannot be viewed.
3. Put a notification clock in every contract. "Without undue delay" is not a number. Write a specific number of hours from the vendor becoming aware of a suspected incident affecting your data, require an initial notice even before scope is known, and require updates on a fixed schedule.
4. Settle who tells the customer. Decide in the contract who notifies regulators and affected people, who pays for it, who drafts it, and how the other party reviews it. Agree on it now, not on the day the regulator calls.
5. Ask about service accounts specifically. The questions that matter for this class of incident are concrete: how many non-human accounts can read our data; how are their credentials stored and rotated; are they restricted by network location; is their behavior baselined and alerted on; and how quickly would you notice one being used from a new place.
6. Map your fourth parties for critical vendors. For each vendor that holds sensitive customer data, ask for its own subprocessors and hosting providers, and record them. When an incident hits a fourth party, you want to know within an hour whether you are exposed.
7. Rehearse a vendor-caused breach. Run a tabletop where the incident starts with a vendor's email, not your own alert. Most incident plans assume you detect first. In vendor incidents you almost never do.

Engineering teams running similar shared platforms

If you run a platform that holds many customers' data, the airlines' experience is the view from the other side. Three checks are worth doing today.

Find every non-human credential with broad read access. List service accounts, API keys and integration users that can read across tenants. For each, record the owner, the purpose, the last rotation date and the last time it was used. Retire anything without an owner.

Alert on new behavior, not only on failed logins. A valid credential used from a new network, at a new time or at a new volume is the pattern here. Baseline each service account's normal sources and query rates and alert on deviation.

Check management endpoints. The heise report described an unauthenticated Spring Boot heap dump. If you run Spring Boot services, confirm that actuator endpoints such as heapdump, env and threaddump are not reachable from outside. A quick check from a machine outside your network:

for path in actuator/heapdump actuator/env actuator/threaddump actuator/configprops; do
  printf "%s " "$path"
  curl -s -o /dev/null -w "%{http_code}\n" "https://your-host.example.com/$path"
done

Anything other than 401, 403 or 404 deserves a look. In configuration, expose only what you need and keep management endpoints on a separate port that is not routed publicly:

management.endpoints.web.exposure.include=health,info
management.endpoint.heapdump.access=none
management.server.port=8081

The management.endpoint.heapdump.access property applies to Spring Boot 3.4 and later; older versions use management.endpoint.heapdump.enabled=false. Our 26 October post has the full walkthrough, including how to find every service that ships the actuator dependency.

Questions to ask a platform vendor this quarter

Questionnaires full of yes or no questions rarely surface the risk in this incident. These questions ask for numbers and evidence instead.

What is confirmed, what is reported, and what is still open

Confirmed by the airlines themselves: the per-airline figures above, the data fields, the access windows in the JAL, ANA and Thai notices, that the access used credentials assigned to an Amadeus system account (Cathay and Asiana), that the airlines' own systems were not breached, and that card data and passwords were not involved.

Confirmed by Amadeus: a vulnerability in a travel booking display environment, that certain booking-display data was accessible, that it has fixed the vulnerability and strengthened monitoring, that there is no evidence payment or financial data was accessed, and that there are no indications of ransomware use.

Reported by a single outlet or second-hand: the SAS figure of 350,164 and its decision not to notify (Realtid, citing the IMY notification); NSM's statements (Realtid and German trade press); Norwegian's notification; Finnair's description of Amadeus as data controller (Aviacionline); Amadeus's detection date of 24 September (ANA, as reported by Aviation Wire).

Still open: who used the credentials, how they were obtained, whether the heise exposure and the credential misuse are connected, how many airlines and agencies are affected in total, how many records were copied out rather than viewed, and whether any of the data has been offered for sale. None of the sources we reviewed reports a claim of responsibility.

How Safeguard helps with this class of problem

Amadeus's own investigation and the airlines' disclosures are the record of this incident. Safeguard's part is the work every company can do around incidents like it: knowing which vendors hold which data, keeping those relationships reviewed with evidence, and having controls ready when the next vendor notice arrives. All of the capabilities below are generally available.

Third-party risk management

Safeguard TPRM is where vendors are onboarded, scored and continuously monitored. It can request SBOMs, projects or products from suppliers, run scans through vendor integrations and apply policies and gates to what comes back, so a supplier's risk score rests on evidence as well as questionnaire answers. The data-at-vendor register from "Fix it without waiting for upstream" fits naturally on each vendor's record, along with the notification clock, the controller and processor split and the subprocessor list. When a vendor appears in the news, its record is where the follow-up tasks live.

Compliance automation with evidence attached

The compliance and GRC suite covers frameworks, controls, evidence, monitoring, tests, questionnaires, risks and vendors, including SOC 2, ISO 27001 and GDPR. Vendor reviews, retention limits, service account rotation and incident notification duties become controls with owners, schedules and stored evidence. When a regulator asks what you knew about a processor and when, the answer is already on file. Safeguard itself is SOC 2 Type I and Type II audited.

Asset discovery, policies and gates

Asset discovery inventories repositories, images, packages, SBOMs, vendors and workloads, then applies guardrails and enforcement to what it finds. Policies, gates and guardrails are enforceable across the organization at build, CI and release, and can be written from plain English prompts. A rule such as "no service may expose actuator heapdump outside the management network" becomes a gate, not a wiki page.

SCA and SBOM monitoring

Software composition analysis builds a full transitive dependency inventory and keeps SBOMs monitored for new vulnerabilities. When the question is "which of our services ship Spring Boot actuator, and which versions?", the answer comes from the inventory in minutes rather than from a week of asking teams.

To see how these fit your own vendors and data, start at https://safeguard.sh.

FAQ

What happened in the Amadeus airline breach?

Someone used login credentials assigned to a system account at Amadeus to view airline booking records held on its platform. The access ran from about August 2023 to September 2026. Amadeus detected it in late September and began notifying airlines on 20 October. At least a dozen airlines have since disclosed that their passengers' booking data was affected.

Which airlines are affected?

Airlines that have disclosed include Japan Airlines and Japan Transocean Air, ANA, Cathay Pacific, Singapore Airlines, Thai Airways, Malaysia Airlines, Finnair, Korean Air and Asiana. SAS and Norwegian have notified their regulators, according to press reports, and Qantas has said it is assessing exposure. A separate Amadeus exposure reported by heise online involved Lufthansa and Condor records.

How many passengers are affected?

Each airline counts differently. JAL reported about 92,000 customers, ANA about 37,800 customers, Cathay about 53,000 bookings, SIA about 46,000 booking records, Thai about 60,529 records, and Finnair about 116,000 bookings on affected flight lists, of which about 750 were opened. SAS reportedly notified its regulator about 350,164 travelers. There is no reliable total.

Was my credit card or password exposed?

The airlines and Amadeus say card numbers, bank details and passwords were not involved, and that no bookings were altered.

What data was exposed?

For most people: name, booking reference, travel date, route and cabin class. For a smaller group at each airline: email address, phone number, passport number, nationality, frequent flyer number, ticket number and seat number.

Were the airlines hacked?

No airline has said its own systems were breached. Every disclosure places the access inside Amadeus's platform, where the airlines' booking records are stored.

Why did it take so long to be told?

According to ANA, Amadeus detected the access on 24 September but airlines were first notified on 20 October, and Cathay on 28 October. Each airline's own regulatory clock started when it was told. The delay between the vendor's detection and the airlines' notification is the gap that contracts and regulators will look at.

What should I do if I was affected?

Be suspicious of any airline message for the next few months and use the airline's own app or website instead of links. Check your upcoming bookings and contact details, accept a new booking reference if offered, change your frequent flyer password and turn on a second factor. If your passport details were in the smaller subset, watch for identity fraud.

Is the heise "display environment" exposure the same incident?

No source has said so. The dates sit close together, and both involve credentials, but neither Amadeus nor any airline has connected them publicly.

What should a company that uses a platform vendor change?

Know what each vendor holds and who has credentials into it, minimize and expire the data you send, write a specific notification clock and a "who tells the customer" clause into contracts, ask vendors about their non-human accounts in detail, map fourth parties for critical vendors, and rehearse an incident that starts with a vendor's email.

Sources

• Amadeus, statement on a vulnerability affecting a travel booking display environment: https://amadeus.com/amadeus-statement-oct
• heise online, 13 Oct 2026, security vulnerability in flight booking system: https://www.heise.de/en/news/Security-vulnerability-in-flight-booking-system-11485328.html
• Japan Cyber Watch, Amadeus breach reaches JAL, ANA and Korean airlines: https://japancyberwatch.com/articles/amadeus-airline-reservation-breach-jal-ana-2026
• Aviation Wire, ANA disclosure of about 37,800 customers: https://www.aviationwire.jp/archives/353359/print/
• Cathay Pacific, personal data security incident involving a third-party service provider: https://www.cathaypacific.com/cx/en_AU/latest-news/security-and-operational-changes/personal-data-security.html
• AeroCorner, Cathay Pacific says Amadeus breach hit about 53,000 bookings: https://aerocorner.com/news/cathay-pacific-amadeus-breach-53000-bookings/
• New Straits Times, 2 Nov 2026, Amadeus fixes booking system vulnerability: https://www.nst.com.my/amp/business/corporate/2026/11/1569011/amadeus-fixes-booking-system-vulnerability-amid-airline-data
• VnExpress International, 4 Nov 2026, Amadeus breach exposes 46,000 SIA bookings: https://e.vnexpress.net/news/news/traffic/amadeus-data-breach-exposes-46-000-bookings-at-world-s-best-airline-5140683.html
• The Star (Reuters), 4 Nov 2026, Singapore Airlines says 46,000 booking records affected: https://www.thestar.com.my/business/business-news/2026/11/04/singapore-airlines-says-46000-booking-records-affected-by-amadeus-breach
• The Record, 4 Nov 2026, Asian airlines announce data breach after IT provider incident: https://therecord.media/asian-airlines-announce-data-breach-it-provider-incident
• Information Age (ACS), 4 Nov 2026, Qantas customers caught up in global airline data breach: https://ia.acs.org.au/article/2026/qantas-customers-caught-up-in-global-airline-data-breach.html
• Nation Thailand, 10 Nov 2026, Thai Airways reports unauthorised access to passenger records: https://www.nationthailand.com/news/general/40073323
• Nation Thailand, Asian airline and bank breaches roundup: https://www.nationthailand.com/business/tech/40073361
• Aviacionline, 9 Nov 2026, Finnair confirms Amadeus data breach exposed around 116,000 of its bookings: https://www.aviacionline.com/english/commercial-aviation/europe/finnair-confirms-amadeus-data-breach-exposed-around-116-000-of-its-bookings_a6af1fc0f4622b038fccd9ad0
• Realtid, 10 Nov 2026, SAS and the data leak, 350,000 travelers: https://www.realtid.se/it-tech/sas-tiger-om-datalackan-350-000-resenarer-far-inget-besked/
• TechCrunch, 15 Jan 2019, flaws in Amadeus' airline booking system: https://techcrunch.com/?p=1769268
• Safeguard, 26 Oct 2026, Amadeus data exposures: Korean Air, Asiana, Lufthansa and Condor: https://safeguard.sh/resources/blog/amadeus-booking-data-exposures-korean-air-asiana-lufthansa-condor-october-2026