Famous Xss Attacks And What They Actually Cost

The last post ended with a promise: the Samy Worm was the first entry in a pattern, not a one-off. Here's the rest of the pattern, and what it actually cost the companies that shipped it.

ExpandA timeline of named XSS incidents from the 2005 Samy Worm through the 2018 British Airways breach and the disclosed Fortnite subdomain issue.

Twitter, 2009: A Parser Bug and a Hover

Four years after Samy, Twitter shipped a bug with a strange trigger: the @ character. Twitter's own HTML parser, the one responsible for turning @username mentions into links, broke on it in a way nobody had tested for.

That broken parsing created a gap where an attacker could inject an onmouseover handler onto a tweet. The handler didn't need a click. The instant someone's mouse merely passed over a malicious tweet-link, it fired jQuery that auto-submitted a hidden status-update form, posting the same malicious tweet from the victim's own account.

It happened twice in the same weekend. Every person who saw an infected tweet and hovered over it became the next carrier, the same worm shape as Samy, four years later, on a much bigger platform.

TweetDeck, 2014: The Cost of Skipping One Escape

TweetDeck was an Electron desktop app, and in 2014, Electron apps didn't ship a Content Security Policy by default the way they're expected to today. That expectation exists largely because of what happened next.

TweetDeck's web client escaped tweet content correctly. The desktop app didn't. A specially crafted tweet, viewed inside the TweetDeck app rather than the browser, retweeted itself automatically the instant it rendered, no click, no hover, just being displayed was enough.

Nobody had to do anything wrong to get hit. They just had to look at their timeline.

eBay's Open Redirect, and McDonald's Comparable Bug

eBay's flagship site had solid protections. Not every property under the eBay umbrella did.

The company's redirectTo query parameter could be pointed at other eBay-owned pages, and some of those subsidiary pages didn't carry the same protections as the main site. That mismatch was the whole vulnerability. An attacker could send a link that looked exactly like a legitimate eBay login. The victim logs in normally, gets redirected through redirectTo to one of the weaker pages, and code gets injected there instead.

From that foothold, attackers manipulated listing prices, changing what sellers thought they were charging. McDonald's had a comparable incident, the same open-redirect-into-injection shape, on a completely different kind of platform. The pattern isn't specific to auction sites. It's specific to any large site where one forgotten corner doesn't get the same scrutiny as the front door.

Angular's Sandbox Flaw: Where Decryption Made Everything Worse

A flaw in an old Angular sandbox implementation let an attacker get script execution on a site that was doing something unusual: decrypting user passwords client-side.

That decision turned an XSS foothold into something far worse than a stolen session. Once the attacker's code was running in the page, it had access to the same decrypted password the page itself was working with, then simply shipped it off to a server the attacker controlled.

This is the clearest illustration in this course of a point worth sitting with. No earlier defense layer applies here, not CORS, not SameSite, not any cookie attribute, because the moment code executes in your origin, everything is same-origin and same-site by definition. There's no boundary left standing to check the request against.

British Airways and Feedify: The Supply Chain Is Part of Your Attack Surface

British Airways didn't write the vulnerable code that hit them. A third-party script called Feedify did, and British Airways had simply loaded it onto their site.

Once that script was compromised, attackers used it to skim data directly off the page in real time as customers typed, no database breach required, no server compromise, just a script reading form fields as visitors filled them in. Roughly a quarter million customers had their names, addresses, credit card numbers, and CVV codes taken this way.

Every third-party script a site loads runs with the same trust as the site's own code. British Airways is the case that makes that fact impossible to ignore, because the company's own engineering was never the weak point. The dependency was.

Fortnite's Forgotten Subdomain

Buried under Fortnite's main domain sat an old, abandoned Unreal Tournament leaderboard page, left over from roughly 15 years earlier and sharing a subdomain with the current game. Nobody had thought about that page in years. It also had no CSRF protection of its own.

Researchers found that an attacker could redirect an authenticated Fortnite user to that forgotten page, then inject code back at the main site through it. This one was disclosed rather than confirmed as actively exploited, so it's worth being precise about what's known versus what's possible. Either way, the lesson holds: a legacy page nobody remembers is still part of your attack surface, even after everyone stopped thinking about it.

The Pattern Isn't Slowing Down

This kind of thing keeps happening past every case study above, and the newest reports are worth mentioning honestly, with exactly the hedge they deserve.

A vulnerability in a VS Code extension surfaced recently, showing this risk extends past the browser into any tool that renders untrusted content, including a code editor. And a screenshot, posted by someone who reportedly now works as a security researcher at a major tech company, claimed a similar technique had been used against a well-known intelligence agency. That claim was never independently confirmed by the original source. Treat it as an unverified, recent report, not a documented case sitting next to Samy or British Airways.

The Same Point the Last Chapter Made, With Higher Stakes

The CSRF chapter made a point worth repeating here, but it lands differently this time. That chapter's damage was real but survivable: a manipulated DVD queue, a spammed friend request, an unwanted like.

XSS's version of "this happens to serious teams too" comes with decrypted passwords and a quarter million stolen credit card numbers attached. British Airways and the Angular sandbox flaw weren't beginner mistakes either. They happened to companies with real engineering organizations, and the cost wasn't inconvenience, it was actual financial and personal data walking out the door.

What This Sets Up

Knowing these attacks happened is one thing. Knowing what actually stops the next one from landing on your own code is the part that matters.

The Essentials

1. Twitter's 2009 worm used a parser bug in the @ symbol to fire jQuery on hover alone, no click required, and it happened twice in one weekend.
2. TweetDeck's 2014 auto-retweet worm is part of why Electron apps now ship a Content Security Policy by default, a practice that wasn't standard yet at the time.
3. eBay's redirectTo parameter exposed weaker subsidiary pages, letting attackers inject code after a legitimate-looking login. McDonald's had a comparable bug.
4. The Angular sandbox flaw mattered more than most, because the site decrypted passwords client-side. Once code ran in the origin, no CORS, SameSite, or cookie attribute was left standing to stop it.
5. British Airways lost a quarter million customers' payment data through Feedify, a third-party script, proof that every dependency a site loads shares its trust level.
6. Fortnite's forgotten 15-year-old subdomain still counted as attack surface. A page nobody remembers is still part of what an attacker can reach.

Next up: sanitization, safe sinks, and the practical layer that actually stops most of this from ever landing.

Further Reading and Watching

• What Did We Learn From the British Airways Cyber Attack?: a breakdown of the Feedify breach and what it revealed about third-party script risk.
• British Airways data breach: a detailed account of the Magecart-linked Feedify compromise and its aftermath.