Code Red (July 2001) and SQL Slammer (January 2003) both exploited flaws for which a patch already existed. Code Red appeared about a month after its patch, and Slammer about six months after Microsoft first reported its flaw. The main lesson is that the patch existing is not the same as the patch being applied.
Code Red, 2001
Per the Wikipedia article, the worm was released on 13 July 2001 and observed on 15 July, with the largest group of infections seen on 19 July. It reached 359,000 infected hosts that day. It targeted Microsoft's IIS web server through a flaw described in Microsoft Security Bulletin MS01-033, CVE-2001-0500, and the patch had been available about a month earlier.
It exploited a buffer overflow by sending a long run of repeated N characters. It also had a calendar: days 1 to 19 of each month it scanned for more servers, days 20 to 27 it attacked fixed addresses including the White House web server, and days 28 to the end of the month it stayed quiet.
Slammer, 2003
The Slammer article says the worm was noticed early on 25 January 2003. It exploited a buffer overflow in Microsoft SQL Server and MSDE. Microsoft first reported the flaw on 24 July 2002, and a patch existed about six months before the worm appeared.
It infected most of its roughly 75,000 victims in about 10 minutes. The complete worm was 376 bytes, small enough for a single packet, and it spread over UDP to port 1434. With no connection setup, it could send as fast as the network allowed.
What the two have in common
Both were old news for defenders and new to attackers who read advisories. Both used a memory bug, a class that remains common. And in both cases, the fix was already public.
What this means for patching today
- Measure time to patch, not just patch availability. A clean advisory feed means nothing if the update sits in a queue.
- Know what is exposed. Slammer's reach came from database servers reachable by a simple protocol. Reduce what is reachable.
- Rank by exploitation, not only severity. Reachability and known exploitation help you choose what to patch first.
Neither worm needed a zero-day. Both needed a gap between publication and deployment, and every organisation has some gap.
A simple way to measure your gap
Take the last ten security updates you applied to internet facing systems. For each, write down the date the fix was published and the date it reached production. The difference is your patch lag. Look at the longest three, and ask what slowed them: testing, approvals, maintenance windows or simply not knowing. Each cause has a different fix. Testing delays call for better automated checks, approval delays for a clearer emergency path, and awareness gaps for a current inventory. Repeat the measure every quarter, and you will see whether things improve.
Quick check
Did a patch exist before Code Red spread?
Yes, about a month earlier, according to the source cited below.
Why did Slammer spread so fast?
It was 376 bytes and used UDP, so one packet could carry it with no connection setup.
Safeguard offers reachability analysis and continuous monitoring to help rank what to fix first, and a free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
