The Third-Party Breach That Ran For Three Years

Someone got into Amadeus’s booking environment in August 2023. Cathay Pacific heard about it on 28 October 2026.

That gap is the story. The exposed passenger names matter, but the three years matter more: a supplier shared by several airlines had an open door, and Cathay Pacific and Japan Airlines learned of it from Amadeus. A third-party breach of this kind tests something no contract clause covers, which is what happens before anyone notices.

What the Amadeus third-party breach exposed

In October, Amadeus said in a short statement that it had become aware of a vulnerability in “a travel booking display environment” and that “certain booking-display data was accessible” through it. The company found no evidence that payment or financial data was accessed. It fixed the flaw and added monitoring and detection. It also said it was in direct dialogue with customers and authorities. The statement gives no date of discovery.

The airlines filled in the rest.

Cathay Pacific’s notice of 30 October says the intruder used login credentials assigned to an Amadeus system account. Access ran from August 2023 to September 2026 and reached around 53,000 Cathay bookings. The records held booking references, passenger names and flight details; a smaller subset also held email addresses, phone numbers, travel document numbers or frequent flyer numbers. Amadeus told Cathay on 28 October and sent further details the next day. Cathay has informed the relevant authorities.

Japan Airlines put its figure at about 92,000 customers, roughly 2,000 of them with passport numbers, and said Amadeus notified it on 23 October, according to BleepingComputer. Malaysia Airlines said on 31 October that customer information processed through Amadeus between August 2023 and September 2026 may have been affected.

Cathay Pacific and Malaysia Airlines both say their own systems were not affected. Cathay will still notify its affected passengers individually.

Where the clock starts in a third-party breach

The GDPR is precise about speed once someone knows. Article 33(1) gives the controller 72 hours “after having become aware” of a breach to notify the supervisory authority. Article 33(2) requires the processor to notify the controller “without undue delay after becoming aware” of it.

Both clocks start at awareness. Neither says anything about how long awareness may take.

Whatever regime applies to each airline, the GDPR shows the mechanism plainly for a European firm. A supplier can keep every notification promise in its contract and still tell you three years after the fact, because the promise runs from discovery and discovery happens inside the supplier. In a third-party breach, a 24-hour notification clause protects the next day. It does nothing for the previous thousand.

This is how a third-party breach can reach the customer as a letter rather than an alert. By the time the processor knows, the access has long since happened, and the controller’s 72 hours start from a date someone else chose.

Concentration turns one weakness into several breaches

Here digital sovereignty stops being a policy phrase, because concentration is what multiplies a third-party breach. One supplier environment served several airlines, so one weakness reached the bookings of Cathay Pacific, Japan Airlines and Malaysia Airlines in the same period.

For an attacker, a shared platform is efficient. The value of a single foothold grows with the supplier’s customer list. For the customer, the arithmetic runs the other way: it cannot see the other tenants, cannot audit their exposure and inherits the supplier’s worst day in full.

The same gap came up last week in who actually understands your third-party AI, where a Bank of England and FCA survey showed firms leaning on vendor assurance and contracts for systems they understand far less well than their own. A contract records what a supplier promised. It does not tell you what the supplier would notice.

None of this is an argument against suppliers. Building your own reservation system, CRM or payroll platform to avoid shared risk would swap one exposure for a larger and more expensive one. The useful work is narrower.

Four questions to ask before the next third-party breach

A notification clause answers one question about a third-party breach: how fast the supplier will call once it knows. These four come before it.

1. How would the supplier notice a valid login doing the wrong thing? Cathay’s notice describes credentials assigned to a system account. Monitoring built to spot break-ins does not catch a key that fits the lock.
2. Which of your data sits in the shared environment, and does it have to? A record that is not there cannot be read.
3. What can you see for yourself? Article 28(3)(h) requires a processor to make available the information needed to demonstrate compliance and to allow for audits, including inspections. Access logs you can read are worth more than a promise to phone.
4. Who else relies on the same environment? A supplier with a long customer list is a richer target. That is a reason to ask about its detection, not a reason to leave.

When your firm is the supplier

For a B2B services firm, the questions come straight back: where you process your clients’ data, a third-party breach at your firm is theirs to report. Article 28(1) obliges every controller to use “only processors providing sufficient guarantees” of appropriate technical and organisational measures. Your clients’ procurement teams can read that sentence too.

After a third-party breach on this scale, the next security questionnaire may well ask how quickly you would spot a valid credential being misused, not only how quickly you would report it. A sales team that can answer with detection rather than notification has the stronger renewal conversation.