← Case Files · The Breach Files

2018 · Airline

British Airways, 2018: twenty-two lines of JavaScript

Case file · 4 min read · Published 14 September 2026

People affected
About 429,612 customers and staff
When it happened
22 June – 5 September 2018
Made public
6 September 2018
How they got in
Malicious JavaScript injected into the payment page — a Magecart-style client-side skimmer
Attributed to
Magecart, a loose set of card-skimming crews; no individual has been charged
What it cost
£20 million ICO fine, reduced from a £183.39 million notice of intent, plus a settled group claim

What was exposed: Names · Billing addresses · Email addresses · Payment card numbers · Expiry dates · CVV security codes

The British Airways breach took 429,612 people's card details, including the three-digit security codes that no company is allowed to store. British Airways did not store them. The attackers did not need it to — they read the numbers out of the customer's own browser as they were typed, and the airline's systems received exactly what they always had.

What happened

On 22 June 2018, a script served by ba.com was modified. The change was small, and it was appended to an existing, legitimate file — a widely used JavaScript library that had been on the site for years. Anyone reviewing the page would have seen a familiar library at a familiar path.

The added code did one thing. When a customer submitted the payment form, it took a copy of what they had entered — name, address, card number, expiry date, CVV — and sent it to a server the attackers controlled. The booking then proceeded normally. There was no error, no delay, no failed payment. Customers completed their purchases, received their confirmations, and flew.

The exfiltration domain was registered as baways.com, with a certificate that made the traffic look unremarkable in any log that only records where connections go. It ran for fifteen days before anyone noticed, and it was a third party — not BA — who did.

How the attackers got in, according to the regulator. The ICO's penalty notice found the initial access came through compromised credentials of an employee of a BA cargo handling supplier, used to log into a remote access gateway that did not require multi-factor authentication. From there the attackers moved laterally, found administrator credentials stored in plaintext on a server, and reached the environment serving the website. The clever part of this attack was the skimmer. The way in was an ordinary chain of missing controls.

Why client-side skimming is so hard to see

Every defence a payment system has is built around the server: the database is encrypted, the CVV is discarded, the card number is tokenised, access is logged. All of that is downstream of the browser. A skimmer sits upstream of it, in the one place where the data is unavoidably in plain text — the form the customer is filling in.

It also leaves almost no evidence on the victim's side. No database was queried unusually, no large export was taken, no volume anomaly appeared anywhere. The data left in thousands of small, individually unremarkable requests from customers' own computers, not from BA's network. Monitoring built to detect bulk extraction had nothing to detect.

The mobile app was affected too, because it loaded the same compromised scripts inside a web view. Users who assumed a native app was a separate, safer path were in the same breach.

The timeline

  1. 22 June 2018 — The modified script goes live; card harvesting begins.
  2. 5 September 2018 — A third party alerts BA; the airline removes the script the same day.
  3. 6 September 2018 — BA discloses publicly and begins notifying customers, initially citing 380,000 transactions.
  4. October 2018 — The affected period is revised to include a further set of reward bookings; the total rises.
  5. July 2019 — The ICO announces a notice of intent to fine £183.39 million, then a record.
  6. 16 October 2020 — The final penalty is set at £20 million, citing BA's representations and the pandemic's impact on aviation.
  7. July 2021 — A group claim brought on behalf of affected customers settles on confidential terms.

What it changed

The ICO published a working description of the attack. The penalty notice is unusually specific about what was missing: multi-factor authentication on remote access, credentials in plaintext on servers, insufficient monitoring of file changes on the website. It became a reference document, because regulators rarely publish that level of technical detail and security teams could take it straight to their own management.

Subresource integrity and content security policy became checkout requirements. Both existed in 2018 and both would have helped: integrity attributes make a browser refuse a script whose contents have changed, and a strict policy limits where a page can send data. PCI DSS version 4.0 later made script management and change detection on payment pages an explicit obligation rather than a recommendation.

Third-party scripts on payment pages got counted. A typical checkout page loaded a dozen or more scripts from other companies in 2018. Each one could read the form. Many retailers responded by stripping payment pages down to the minimum, or by moving card entry into an iframe hosted by the payment processor so the merchant's own page cannot read it.

The size of the first number stopped being the story. The gap between £183 million and £20 million was widely reported as a climbdown. What it actually demonstrated is that headline regulatory figures are opening positions, and the final number is a negotiation about findings, remediation and circumstance.

If you were affected

  1. Assume a card used on ba.com in that window is compromised, replaced or not. Card details from 2018 still circulate; they are simply worth less than fresh ones.
  2. Check statements for small test transactions rather than large ones. Stolen cards are usually validated with a trivial charge before anything significant is attempted.
  3. Expect the address and email to outlive the card. The card number expires. The name, billing address and email do not, and they are what makes a follow-up phishing message convincing.
  4. Treat any "British Airways compensation" contact as hostile until proven otherwise. Breach settlements attract impersonators, and a real scheme never asks for card details to pay you.

Checked against every breach on record, against public breach data only. Your address is not sent to us as a form and is not stored — it is handed straight to the lookup tool in your own browser. See the privacy policy.

Questions people ask

How were CVV codes stolen when nobody stores them?

Because they were never stored. Card rules forbid keeping the CVV after a transaction, and BA did not keep it. The skimmer captured the code in the browser at the moment the customer typed it, before it reached the airline's systems at all. This is exactly why client-side attacks are so effective against payment pages: they read the data upstream of every rule about what may be retained.

Why was the British Airways fine reduced from £183 million to £20 million?

The £183.39 million figure published in July 2019 was a notice of intent, not a fine. It fell after BA made representations about the ICO's findings, after the regulator revised parts of its case, and after it took account of the effect of the COVID-19 pandemic on the aviation industry. The final penalty notice was issued in October 2020.

Was I affected by the British Airways breach?

BA contacted affected customers directly. The window was 22 June to 5 September 2018, and it covered bookings made on the website and the mobile app. If you paid BA in that period and were never notified, you were most likely outside it — but a card used then should be treated as compromised regardless, and any card still in use from that era is long overdue for replacement.

What is Magecart?

Magecart is not one group. It is the umbrella name for many crews running the same technique: get a small piece of JavaScript onto a checkout page, read the payment fields as they are filled in, and send a copy to a server you control. They usually get in through a third-party script the site embeds — analytics, chat widgets, ad tags — rather than through the site's own code.

Sources

Read next

Case files are written from the public record: regulatory findings, court filings, company disclosures and contemporaneous reporting, cited above. Figures are the ones the organisation or its regulator finally settled on, which is often not the number first reported — where that differs, the page says so. Disputed accounts are marked as disputed rather than resolved in either direction.

← All case files Breach archive →