# The Lesson Code Red Taught in 2001 That We Still Haven't Learned


July 2001. A worm called Code Red crawled across the internet and infected roughly 359,000 hosts in under fourteen hours. It targeted Microsoft IIS servers, required no user interaction, and spread through a buffer overflow vulnerability that Microsoft had patched a month earlier. The patch existed. Most organizations just didn't know what servers they were running.


That's the part that should sting today.


Twenty-five years on, BeyondTrust CTO Marc Maiffret — one of the researchers who first identified Code Red — is making the case that the worm's real legacy isn't about buffer overflows or IIS 4.0. It's about the foundational failure that let Code Red spread so fast: organizations deploying technology they couldn't fully inventory, in environments they didn't fully understand, with patch cadences built for a slower threat landscape.


Sound familiar?


## The Worm That Wasn't the Point


Code Red gets remembered as a technical footnote — a buffer overflow, a fixed patch, a historical curiosity from the dial-up era. That reading misses what actually happened.


The reason Code Red spread wasn't the exploit. The exploit was known. The reason it spread was that most organizations had no accurate inventory of their IIS servers. Sysadmins believed they knew what was running. They were wrong. Web servers had been spun up by application teams, contractors, and developers who didn't loop in security. IT departments inherited infrastructure they'd never catalogued. The worm didn't beat the defenders on technical sophistication — it beat them on visibility.


That lesson produced real structural change. It accelerated the adoption of vulnerability scanners, formalized asset management as a security discipline, and laid conceptual groundwork for what would eventually become attack surface management. The 2001 moment was painful enough that it moved practice.


The question Maiffret and his BeyondTrust colleagues are now asking — and it's a fair question — is whether we'll need an equivalent "AI Code Red" before the industry takes AI visibility seriously.


## Shadow AI Is Just Shadow IT With a Better PR Team


The parallel to today is uncomfortably direct.


In the late 1990s and early 2000s, the term "shadow IT" hadn't quite entered the mainstream, but the phenomenon was everywhere: business units spinning up servers and applications outside of IT's purview, driven by the speed of internet adoption and the availability of cheap, accessible technology. Security teams discovered these systems the hard way — during incident response, after the breach.


Today, employees across virtually every industry are connecting AI tools, AI agents, and AI-powered SaaS products to enterprise systems without meaningful security review. Sometimes it's a developer wiring Claude into an internal workflow. Sometimes it's a sales team running customer data through an LLM to generate pitches. Sometimes it's an autonomous agent with read access to cloud storage that nobody has explicitly authorized.


Nobody is keeping a list.


The 2001 IIS problem and the 2026 AI problem share a common shape: a technology wave moving faster than governance can follow, with organizations unable to answer a basic question — what are we actually running, and what does it have access to?


## What Attackers See That Defenders Don't


Here's what makes shadow AI particularly interesting from an attacker's perspective, and what the Code Red comparison illuminates clearly.


Code Red's effectiveness wasn't about exploiting secured systems. It was about exploiting the gap between what organizations believed their attack surface was and what it actually was. Attackers don't need to defeat your defenses if they can find the systems your defenses don't cover.


AI agents and AI-integrated workflows create that same gap in several ways:


  • Data access without accountability. An AI tool that an employee connects to their email, calendar, and cloud storage has broad data access that wouldn't survive a formal security review — but nobody ran one.
  • Inference-layer exposure. Even when underlying data is protected, AI tools can be used to extract, summarize, or exfiltrate information in ways that bypass traditional DLP controls.
  • Supply chain opacity. Third-party AI tools come with their own model providers, data retention policies, and training pipelines. Organizations using these tools often have no visibility into where inputs go.
  • Agent-to-agent trust. Multi-agent architectures introduce new trust boundaries that most organizations haven't thought through. What happens when one AI agent passes instructions to another?

  • The IIS servers that Code Red hit weren't the crown jewels. They were the exposed perimeter that got missed. In an AI context, the equivalent isn't the LLM itself — it's the poorly governed agent with access to your Slack workspace, your customer database, or your internal ticketing system.


    ## Patching Is Not Enough This Time


    One uncomfortable difference between 2001 and now: the Code Red problem had a clear remediation path. Patch the servers you knew about, find the ones you didn't know about, patch those too. Defined, executable, finite.


    AI security doesn't resolve cleanly the same way. You can't patch your way out of a governance problem. The equivalent work — inventorying AI tools in use, understanding what data each one touches, establishing approval workflows for new AI integrations, monitoring AI agent behavior at runtime — requires sustained organizational commitment, not a one-time fix cycle.


    This is why AI Security Posture Management (AI-SPM) is emerging as a category, and why the framing of "you can't secure what you don't know you have" remains the right place to start. Organizations that haven't yet done even basic discovery — what AI tools are our employees using, what enterprise data can those tools access — are operating exactly like the IT teams of 2001 who didn't know which IIS servers were running.


    ---


    ## HackWire Analysis


    The Code Red retrospective is a useful hook, but let's be direct about what's really happening here: the security industry is having the same conversation it has at every technology inflection point, and the fact that the lessons keep needing to be relearned should itself be the story.


    We saw this cycle with cloud adoption. Security teams spent years playing catch-up after business units went directly to AWS and Azure without IT involvement. We saw it with mobile devices, with IoT, with containerization. Every wave brought the same dynamic: technology moves fast, governance moves slow, and the gap between them is where attackers live.


    What's different with AI is scale and speed. A developer can spin up an autonomous agent with broad system access in an afternoon. That same developer couldn't stand up an IIS server in 2001 without at least some infrastructure involvement. The friction is gone.


    The timing of this conversation also matters: we are almost certainly closer to an AI-era Code Red moment than most defenders realize. The conditions are identical — widespread deployment of complex technology, inadequate inventory, immature patching and governance practices, and an attacker community actively probing for the exposure. The question isn't whether a high-profile AI-related breach will crystallize this problem the way Code Red crystallized the asset management problem. The question is whether organizations use this window to get ahead of it.


    For defenders, the immediate priority isn't buying AI-SPM tooling. It's answering a question your CISO should be asking right now: if I asked you to enumerate every AI tool connected to enterprise data in our environment, how long would it take, and how confident would you be in the answer? If the honest answer is "days" and "not very" — that's the vulnerability. Start there.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)