SQL Slammer: The 376-Byte Worm That Infected 75,000 Servers in 10 Minutes and Is Still the Fastest Malware Ever

2026-08-09-13 min read

#sql-slammer#sql-server#buffer-overflow#udp#worm#cve-2002-0649#bank-of-america#atm#network-impact#patch-management

At 05:30 UTC on January 25, 2003, a single 376-byte UDP packet began propagating across the internet. By 05:40 - ten minutes later - the number of infected hosts had doubled seven times. By 06:00, SQL Slammer had infected nearly 75,000 systems. Routers began failing under the scan load. Bank of America's ATM network went offline. The internet itself became noticeably degraded across multiple continents. The entire event was effectively over - the worm had reached most of its available targets - before most people in North America had woken up.

SQL Slammer remains the fastest-spreading piece of malware in internet history. It doubled in size every 8.5 seconds during its exponential growth phase, reaching its scanning ceiling in approximately 10 minutes. No worm before or since has spread as fast. The technical reasons for its speed are inherent to its design: it was stateless, carried entirely in a single UDP packet, required no file I/O, and needed no OS interaction beyond sending packets. It was, in the most precise technical sense, the fastest possible worm for its vulnerability class.

The Vulnerability: SQL Server Buffer Overflow

SQL Slammer exploited a heap buffer overflow in Microsoft SQL Server 2000's resolution service - specifically the SQL Server Resolution Service that ran on UDP port 1434. This service existed to help clients figure out which TCP port a named SQL Server instance was running on. CVE-2002-0649 was disclosed in July 2002. Microsoft released a patch (MS02-039) the same day, six months before the Slammer outbreak.

The overflow was triggered by sending an oversized packet to UDP port 1434. The resolution service copied the packet data into a fixed-size stack buffer without bounds checking, overwriting the return address. The shellcode then caused the SQL Server process to generate random IP addresses and send the worm payload - the 376-byte UDP packet - to each generated IP on port 1434.

[TECHNICAL NOTE]

SQL Slammer's 376-byte payload is one of the most elegant pieces of malicious code ever written from a pure efficiency standpoint. The entire worm - including exploitation shellcode, random IP generation, and self-propagation - fits in a single UDP datagram. UDP is connectionless: no handshake, no acknowledgment, no session state. The worm could send thousands of packets per second without waiting for any response. Compare this to TCP-based worms like Code Red, which needed to complete a three-way handshake before exploiting each target. The UDP approach gave Slammer a fundamental throughput advantage. Additionally, because the worm ran entirely in the SQL Server process's address space and used Windows sockets for packet transmission, it required no disk writes, no file creation, and no registry modifications - it left almost no persistent forensic traces on infected systems. When the SQL Server process was restarted, the infection was gone. This was both a characteristic of its simple design and, coincidentally, a property that made cleanup straightforward: patch, restart SQL Server, done.

Impact: Saturated Networks and Failed ATMs

Slammer's scanning traffic was so intense that it caused collateral damage far beyond SQL Server hosts. Each infected machine generated scanning traffic at rates that saturated many routers' packet-processing capacity. The worm effectively created a distributed denial-of-service attack against the internet's routing infrastructure as a side effect of its propagation. Packet loss spiked dramatically on internet backbone links, causing degraded performance for all traffic, not just SQL Server traffic.

Bank of America's ATM network failed because its ATM transaction processing relied on SQL Server infrastructure that became unreachable. 13,000 ATMs went offline. Continental Airlines experienced check-in system failures. The city of Seattle's 911 call system was degraded for hours. South Korea and New Zealand experienced internet connectivity problems severe enough to be publicly reported. The 2003 blackout across the US Northeast - which occurred six months later - was partly attributed in NERC's postmortem to an energy management system running an unpatched version of SQL Server 2000 that would have been vulnerable to Slammer.

[WARNING]

One of the most important aspects of the SQL Slammer incident is how it undermined the conventional wisdom about patch management timelines. The conventional enterprise security advice in 2003 was that organizations should test patches for 30-60 days before deploying them to production systems, to ensure the patch didn't break production applications. Microsoft had released the Slammer patch in July 2002. The Slammer outbreak was January 2003. By the conventional testing timeline, many organizations would have been in the middle of their patch testing window or only recently finished. The worm demonstrated that for critical remotely-exploitable vulnerabilities in internet-facing infrastructure, 30-60 day patch testing timelines were not operationally viable - the vulnerability window was measured in months at most, and attackers would have working exploits within days to weeks of disclosure. The argument that "we need to test patches before deploying them" remains valid, but Slammer demonstrated that the testing window for critical vulnerabilities needed to compress dramatically, especially for services directly exposed to the internet.

What Slammer Taught Defenders

SQL Slammer spread exclusively via UDP port 1434. Organizations that filtered UDP port 1434 at their perimeter were completely protected, even with unpatched SQL Server installations. This was a stark demonstration of network segmentation's value: the organizations hardest hit were those that had SQL Server instances with direct internet exposure or whose internal networks allowed the worm to propagate without filtering. The organizations that escaped were not necessarily better patched - they were better segmented.

The incident accelerated practical thinking about network segmentation and the principle of least exposure. SQL Server's resolution service had no business being accessible from the internet for the vast majority of installations, yet tens of thousands of deployments had it exposed. The appropriate control was not just patching but ensuring that database services were never accessible from untrusted networks in the first place - a defense-in-depth principle that patching alone could not substitute for.

[IOC]

SQL Slammer technical summary: outbreak date January 25, 2003, 05:30 UTC. Vulnerability: CVE-2002-0649, heap buffer overflow in SQL Server 2000 Resolution Service. Affected service: UDP port 1434 (SQL Server Browser / Resolution Service). Worm size: 376 bytes (single UDP datagram - smallest self-propagating worm by payload size). Patch availability: MS02-039, released July 24, 2002 (six months before outbreak). Propagation: stateless UDP scanning, random IP generation, exponential growth - doubles approximately every 8.5 seconds initially. Infection peak: approximately 75,000 hosts in under 10 minutes. Scanning rate at peak: estimated 55 million scans per second globally. Network impact: significant packet loss on internet backbone links; South Korea and New Zealand partially disconnected; multiple enterprise networks degraded. Named affected systems: Bank of America ATMs (13,000 offline), Continental Airlines check-in, Seattle 911 dispatch, South Korean internet infrastructure. Cleanup: patch MS02-039 + restart SQL Server process (no persistent file footprint). Contributing factor: NERC postmortem on August 2003 Northeast Blackout cited SQL Server 2000 vulnerability. Authorship: officially unknown; exploit code based on earlier proof-of-concept published in security research. Still considered fastest-spreading worm in internet history by any metric.