Pulp sci-fi illustration of a tiny glowing data packet travelling along a thick cable that loops round the end of an intact concrete wall and runs through a doorway into a calm, empty 1950s control room with dials and dark screens

376 bytes, ten minutes: what SQL Slammer still teaches us 23 years on

The Long View. In January 2003 a worm a few hundred bytes long took down networks around the world in the time it takes to boil an egg, using a hole that had been patched six months earlier. One of the networks it reached belonged to a nuclear power station in Ohio, which had been shut down since February 2002 for reactor-head corrosion repairs, so no reactor was running when it hit. The lessons are older than some of the people now paid to learn them. Sources checked on 26 October 2026.

Saturday morning, 05:30 UTC

Just before 05:30 UTC on Saturday 25 January 2003, somebody released a worm that the researchers who later measured it called “the fastest computer worm in history” (CAIDA, The Spread of the Sapphire/Slammer Worm (opens in a new tab)). It had no attachment, no email, no link and nothing for anybody to click. It was 376 bytes of code, which with its headers made a single 404-byte UDP packet, fired at port 1434 on random addresses. If the address belonged to an unpatched copy of Microsoft SQL Server 2000 or its little brother, MSDE 2000, the machine was infected and started firing packets of its own.

Nobody was at their desk. That turned out not to matter, because nobody at their desk could have done anything either.

I mention the size because people assume serious damage needs serious effort. It needs one mistake repeated in enough places.

Anatomy of ten minutes

The flaw was a stack buffer overflow in the SQL Server Resolution Service, the bit that tells clients which port a database instance lives on. It listens on UDP port 1434, and a carefully crafted packet from an unauthenticated stranger could run code in the security context of the SQL Server service (CERT/CC, VU#484891 (opens in a new tab); NVD, CVE-2002-0649 (opens in a new tab)).

UDP is the important part. A worm using TCP has to wait for a handshake before it can do anything. Slammer did not wait for anyone. It sprayed packets as fast as each infected machine’s network connection would carry them, so its speed was limited only by bandwidth. In the first minute the infected population doubled every 8.5 seconds. It hit a peak of more than 55 million scans a second in under three minutes, and it infected most vulnerable hosts within about ten minutes, more than 90 per cent of them by the CAIDA team’s estimate. The researchers counted at least 75,000 infected hosts, “perhaps considerably more” (CAIDA (opens in a new tab)).

For comparison, Code Red in 2001 took about 37 minutes to double. Slammer spread, in CAIDA’s words, “nearly two orders of magnitude faster than Code Red”. Their conclusion is the sentence I would pin above every operations desk: “there is no conceivable way for system administrators to respond to threats of this speed.”

No payload, plenty of damage

Slammer did not delete files, steal data or demand money. CERT’s advisory that day said that beyond scanning for new hosts, it had “no other payload” (CERT Advisory CA-2003-04 (opens in a new tab)). It did not need one. The traffic alone was the weapon. Links saturated, database servers fell over, and according to CAIDA the knock-on effects included “canceled airline flights, interference with elections, and ATM failures”.

That is CAIDA’s list, quoted as theirs. A worm harmless by the standards of the people who write malware was harmful enough to cancel flights. The researchers drew the obvious conclusion: if it had carried a malicious payload, “the effects would likely have been far more severe.”

The response was quick: within an hour, many sites were filtering UDP port 1434. CAIDA again: “The earliest filtering was initiated long after the worm had infected almost all of the susceptible hosts.” CERT was equally blunt about ingress and egress filtering: it limits the damage infected machines can do, but provides “no protection against the initial infection” (CA-2003-04 (opens in a new tab)). By the time you have spotted it, the worm has finished.

Six months’ notice

Here is the part that still annoys me. Microsoft published Security Bulletin MS02-039 on 24 July 2002, rated it Critical and told administrators to “install the patch immediately” (Microsoft, MS02-039 (opens in a new tab)). CERT/CC records the same public date, 24 July 2002, and published its own note two days later (VU#484891 (opens in a new tab)). The bulletin even suggested blocking port 1434 at the firewall as a mitigation.

So when Slammer arrived, the industry had six months’ notice. The patch existed, the workaround was published and the port number was public. What did not exist was a reliable way of knowing where all the vulnerable copies were.

Many of them were not called SQL Server. Microsoft updated its bulletin the day after release to note that MSDE 2000, the desktop engine that ships inside other people’s products, was affected too, and CERT warned that the flaw “also affects any products that include” it (VU#484891 (opens in a new tab)). You cannot patch software you do not know you own.

Davis-Besse: the firewall that did its job

Now the OT chapter, which is usually told badly.

The Davis-Besse nuclear power station in Ohio had been shut down since 16 February 2002. It went down for a refuelling outage, during which the operator found severe corrosion of the reactor pressure vessel head, and the NRC kept it shut while that was repaired. The NRC did not approve a restart until 8 March 2004 (NRC, EA-03-214, approval to restart Davis-Besse, 8 March 2004 (opens in a new tab)). So when Slammer arrived in January 2003, the reactor was not operating.

The worm still got in. The NRC’s account, in Information Notice 2003-14, is worth reading in full (NRC Information Notice 2003-14, 29 August 2003 (opens in a new tab)). The operator’s corporate firewall had port 1434 closed, which was exactly the right rule. But one of its consultants had a T1 line into the corporate network behind the firewall, and that connection “bypassed all the access control policies that the corporate firewall was enforcing”. The consultant’s company server was infected, the worm came down the T1, and the corporate network was linked to the plant network.

The traffic slowed the site’s computers through the day. By 4.50pm local time the Safety Parameter Display System was unavailable, and it stayed that way for 4 hours 50 minutes. By 5.13pm local time the plant process computer was lost for 6 hours 9 minutes.

Then the sentence that matters, in the NRC’s own words:

“Although the operators were burdened by these losses, the event was not deemed significant since the plant control and protection functions were not affected.”

So: a reactor already shut down for repairs, plant control and protection functions unaffected, and an event the NRC did not deem significant. This was not a near-miss. It was something more useful than that: a clean demonstration, at no cost to anyone’s safety, of how a good firewall rule fails.

The NRC named two primary causes. The first was the T1 connection behind the firewall. In February 2002 the NRC had issued a security order alerting licensees to external connections that bypass network protections. The licensee’s IT staff had dealt with it, but, as the notice puts it, “their activities were not communicated to the plant computer engineers.” The second was that the plant computer engineers “had not been aware of the security patch” at all.

The corrective actions are a checklist that has aged better than most things written in 2003. Document every external connection to the internal network. Install the patch. Put a firewall between the plant network and the corporate network. Monitor and filter traffic into the plant network to the same standard as the corporate firewall. Give the computer engineers a process to review security patches and install them within an acceptable time.

What has changed, and what has not

The worm itself is history. The conditions that made it possible are not.

Internet-facing services still get exploited soon after their flaws are published; the only difference is that the services are now VPN gateways, firewalls and file-transfer appliances rather than database listeners. CISA keeps a public Known Exploited Vulnerabilities catalogue (opens in a new tab) precisely because “patch it eventually” is not a plan. Vendor and remote-support links into industrial networks are still the cable that goes round the firewall. Bundled components are still hiding inside products, and old kit is still running long after anyone can patch it, which is why the NCSC publishes guidance on managing obsolete products (opens in a new tab).

And IT and OT teams still, too often, keep separate patch feeds, separate asset lists and separate ideas about who is responsible for the line the consultant asked for. If you want the basics of how the two worlds differ, our OT Security 101 primer starts there. If the honest answer to “can we patch it?” is no, our guide When there’s no patch covers finding and fencing what you cannot fix.

Lazarus’s rules of thumb

  • A firewall is a promise. Every cable that goes round it breaks the promise.
  • If nobody can tell you who owns a server, it’s already the worm’s.
  • Patches don’t install themselves because you’ve read the bulletin.
  • The software you forgot you bought is still listening.
  • When IT and the plant floor don’t talk, the attacker does the introductions.

Five things to do this month

  • ☐ Map every external connection into your networks, including the supplier and support lines, and check each one actually goes through the controls you think it does.
  • ☐ Find the bundled databases and other components hiding inside third-party products, and add them to the asset list with an owner.
  • ☐ Patch internet-facing services first, and check the known-exploited list rather than waiting for the monthly cycle.
  • ☐ Filter egress as well as ingress, so an infected machine cannot spray the outside world or the plant network.
  • ☐ Give OT and plant engineers the same patch and advisory feed as IT, and agree in writing who acts on it.

None of this is new. That is rather the point. The record from 2003 already tells you what to do; the only question is whether you have done it.

Sources

  1. CAIDA (Moore, Paxson, Savage, Shannon, Staniford, Weaver), The Spread of the Sapphire/Slammer Worm, 2003. https://www.caida.org/catalog/papers/2003_sapphire/ (opens in a new tab). Retrieved 26 October 2026.
  2. Microsoft Security Bulletin MS02-039, Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution, published 24 July 2002, updated 31 January 2003. https://learn.microsoft.com/en-us/security-updates/securitybulletins/2002/ms02-039 (opens in a new tab). Retrieved 26 October 2026.
  3. CERT/CC Vulnerability Note VU#484891, date public 24 July 2002, first published 26 July 2002. https://www.kb.cert.org/vuls/id/484891 (opens in a new tab). Retrieved 26 October 2026.
  4. CERT Advisory CA-2003-04, MS-SQL Server Worm, 25 January 2003 (archived copy). https://web.archive.org/web/20031205025344/http://www.cert.org/advisories/CA-2003-04.html (opens in a new tab). Retrieved 26 October 2026.
  5. NVD, CVE-2002-0649. https://nvd.nist.gov/vuln/detail/CVE-2002-0649 (opens in a new tab).
  6. US Nuclear Regulatory Commission, Information Notice 2003-14, Potential Vulnerability of Plant Computer Network to Worm Infection, 29 August 2003. https://www.nrc.gov/docs/ML0324/ML032410430.pdf (opens in a new tab). Retrieved 26 October 2026.
  7. US Nuclear Regulatory Commission, EA-03-214, Approval to Restart the Davis-Besse Nuclear Power Station, Closure of Confirmatory Action Letter, and Issuance of Confirmatory Order, 8 March 2004. https://www.nrc.gov/reading-rm/doc-collections/enforcement/actions/reactors/ea03214 (opens in a new tab). Shutdown on 16 February 2002 and extended shutdown for the reactor pressure vessel head degradation. Retrieved 26 October 2026.
  8. CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab).
  9. NCSC, Obsolete products, device security guidance. https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/obsolete-products (opens in a new tab).

Follow Cyber-Threat.net RSSFeedly (opens in a new tab)X (opens in a new tab)Bluesky (opens in a new tab)LinkedIn (opens in a new tab)