The Samy Worm: How One XSS Took Down MySpace in 20 Hours

On 4 October 2005, Samy Kamkar posted a specially crafted payload to his MySpace profile. Anyone who viewed the profile silently had their own account modified: Samy was added as their friend, the phrase "but most of all, samy is my hero" was appended to their profile, and, critically, a copy of the payload was added to their profile too. Every viewer became a carrier. It spread to over a million accounts in under twenty hours, faster than any worm of its time, and MySpace had to take the entire site offline to stop it and clean up. The whole thing was a single piece of stored cross-site scripting, and it remains the canonical example of an XSS worm.

I keep coming back to the Samy worm for two reasons. It is the clearest demonstration that XSS is not a "just an alert box" bug, it can self-propagate across a platform, and it is a masterclass in defeating input filters, because MySPace had filters, and Samy walked through every one of them.

What made it a worm

A normal stored XSS payload runs once, in the browser of whoever views the malicious page. Samy's payload did something more: while running in a viewer's browser, with that viewer's logged-in session, it used the site's own functionality to write a copy of itself onto the viewer's profile. That is the self-propagation step that turns a one-off XSS into a worm. Viewer A sees Samy's profile and gets infected; now viewer B sees A's profile and gets infected; and so on, doubling outward. With a million-plus active MySpace users viewing each other's pages, the growth was exponential and the spread was measured in hours.

Everything the payload did, it did as the victim, using the victim's own session, because that is what XSS gives you: code execution in the victim's browser with the victim's identity. Adding a friend, editing a profile, these were normal actions the victim was allowed to perform, and the script simply performed them on the victim's behalf.

The filter-bypass chain

This is the part every web developer should study, because MySpace was not careless. It filtered user input to block scripts, and Samy's payload is a chain of techniques for getting executable JavaScript past a blocklist. The details below are from Kamkar's own technical writeup, and they are the reason blocklist filtering is considered a losing strategy.

• <script> was blocked, so the script ran from CSS instead. MySpace stripped <script> tags, so the payload ran the code from a CSS context: a style attribute set the element's background to a javascript: URL, which the browsers of the day would execute. The code ran without a single <script> tag.
• The literal word "javascript" was stripped, so it was split apart. The filter removed the string javascript. Browsers, however, tolerated a newline in the middle of it, so writing it as java\nscript (with a real line break) survived the filter and the browser still read it as javascript.
• Quotes were stripped, so they were rebuilt in code. With quote characters filtered out, the payload constructed the quotes it needed at runtime using String.fromCharCode() with the character codes for the quote marks.
• Banned identifiers were split and reassembled. Words the filter looked for, like innerHTML, were broken into pieces and concatenated back together in the script (an 'inne' + 'rHTML' style trick), then evaluated, so the dangerous identifier never appeared intact in the stored text.

Each of these is a small, clever evasion. Together they are a complete proof that a filter which tries to enumerate and block "bad" patterns will lose, because there are always more encodings, more browser quirks, and more ways to express the same code than the blocklist anticipates. The defence that actually works is the opposite stance: encode all output for its context and allow only a known-safe set, rather than trying to spot every dangerous input.

The trick that still matters most: XSS defeats CSRF tokens

The single most important technical lesson in the worm is how it defeated MySpace's protection on the "add friend" and profile-edit actions. Those actions were guarded by an anti-CSRF token, a random value that had to be submitted with the request to prove it came from a legitimate page, exactly the standard defence against cross-site request forgery.

It did not help, and the reason is fundamental. The worm's code was running inside MySpace's own pages, in the victim's browser, with the victim's session. So it simply did what the page itself would do: it made a request to fetch the confirmation page, read the anti-CSRF token straight out of the returned HTML, and then submitted the action with that valid token, all through same-origin requests as the victim.

This is the canonical demonstration that XSS defeats CSRF tokens. A CSRF token protects against a different site forging a request, because that site cannot read the token. But code running via XSS is on the same origin, so it can read any token on the page. Once an attacker has script execution in your origin, same-origin protections meant to stop cross-origin attacks no longer apply. It is why XSS sits near the top of the web vulnerability taxonomy: it undermines other defences.

The aftermath

Samy Kamkar did not profit from the worm, and its payload was juvenile rather than destructive (a friend request and a catchphrase). It was still a serious computer-crime case: the US Secret Service raided Kamkar, and he pleaded guilty to a felony, receiving probation, community service, and a restriction on his computer use. He went on to become a well-known security researcher, later known for projects like the evercookie and SkyJack.

The lasting significance is not the prank. It is that the Samy worm proved, at massive scale and in public, that a stored XSS is a platform-level threat, and it did so in a way that helped demonstrate the need for context-aware output encoding and allow-listing over the input-blocklist approach it so thoroughly defeated. Content Security Policy, which emerged years later, is now an additional layer on top of that.

Where to go next

For the mechanics and modern defences, the cross-site scripting deep dive covers the variants and the output-encoding-plus-CSP approach that the Samy worm argued for by counterexample, and stored XSS is the specific variant the worm used. The CSRF-token lesson connects to cross-site request forgery and to stealing session cookies via XSS. For the full set of web attack classes, see the web application security vulnerabilities taxonomy.