The Intelligent Worm: Adaptive Malware

A note on scope and intent. This is a defensive threat-modeling essay in the tradition of Staniford, Paxson, and Weaver’s How to 0wn the Internet in Your Spare Time (USENIX Security 2002) — a paper that described worm dynamics precisely so that defenders could reason about them. Everything here is at the level of architecture, dynamics, and countermeasures. There is no exploit code, no propagation implementation, and no operational recipe. The point is to stress-test the assumptions our current defenses rest on before an adaptive adversary does it for us.

Preprint downloads. A self-contained, arXiv-style version of this essay is available with full bibliography: PDF · LaTeX source. The .tex file is self-compiling under standard distributions (tectonic, pdflatex, lualatex).

The single assumption underneath most of our defensive posture is that malware is static between releases. An exploit is discovered, weaponized, and shipped by a human author; defenders reverse it, extract a signature or a patch, and the specific threat decays. The whole signature-and-patch industry — antivirus definitions, IDS rules, CVE-driven patch cycles — is an answer to an adversary whose capabilities are fixed at authoring time.

This essay asks what happens to that assumption if the exploitation capability is not fixed but regenerated by an onboard reasoning loop. I’ll call the hypothetical result an Intelligent Worm, and I want to be careful about what is and isn’t novel about it. The propagation machinery — scanning, self-replication, persistence — is old and well understood. What changes is that the infection vector stops being a finite asset carried from the author and becomes an adaptive capability the program produces on the fly. That one change, I’ll argue, is best understood not as “a smarter worm” but as a change in the epidemiology of the threat.

Worms, precisely

A worm is self-replicating malware that spreads across a network without a human running it. That autonomy is the whole distinction:

• Virus — attaches to a host file or program; spreads when a person executes the infected file.
• Worm — a standalone program that copies itself to new hosts over a network; no user action required.
• Trojan — disguised as benign; relies on the user being fooled.

Worms are defined by network self-propagation, and that is exactly why they have historically produced the fastest, largest outbreaks. The security literature decomposes a worm into four functional parts:

1. Target discovery (the scanner). How it finds the next victim: random IP generation, local-subnet sweeps, harvesting the host’s own address book / known_hosts / config files, or querying a search engine for exposed services. The discovery strategy sets the scan rate, which largely determines spread speed.
2. Propagation vector. How it gets onto the next host — almost always by exploiting a vulnerability: a remote memory-corruption bug in a network service, weak or default credentials, an unpatched RCE, a misconfiguration. This is the “how it copies itself over” step, and it is the component the Intelligent Worm proposes to make adaptive.
3. Payload. What it does beyond spreading — which can be nothing (spread-only), or theft, a backdoor, ransomware, a botnet agent, or destruction. Propagation and payload are independent; a worm can be a pure delivery mechanism.
4. Self-replication and persistence. It copies its code to the new host, launches it, often installs persistence to survive reboots — and the new host repeats the cycle. This recursion is what produces exponential growth.

The lifecycle is a loop:

   ┌─────────────────────────────────────────────┐
   │ 1. Running on an infected host               │
   │ 2. Scan the network for reachable targets    │
   │ 3. For each target: probe for a weakness     │
   │ 4. Exploit it → gain code execution remotely │
   │ 5. Transfer a copy of itself to the victim   │
   │ 6. Execute the copy → new host now infected  │
   │ 7. (Optionally) run payload, install persist │
   │ 8. New host returns to step 2 — recursion    │
   └─────────────────────────────────────────────┘

The epidemiological frame is the right one

Worm propagation is not like an epidemic; it is modeled with literally the same mathematics. The Slammer analysis (Moore et al., Inside the Slammer Worm, IEEE S&P 2003) and the How to 0wn the Internet paper both use the classical susceptible–infected (SI/SIR) framework from mathematical epidemiology. The lineage is explicit: the SIR model and the reproductive number come from Kermack and McKendrick’s 1927 epidemic theory; Kephart and White (IEEE S&P 1991) first mapped it onto computer viruses; and recent work fits compartmental models directly to real malware traces — Chernikova et al.’s SIIDR model (arXiv:2208.03276) reproduces WannaCry’s spread across fifteen real infection traces and derives its basic reproduction number in closed form. The quantity that governs whether an outbreak takes off or dies is that basic reproductive number $R_0$: the expected number of new hosts a single infected host goes on to infect.

The epidemic threshold is the familiar one:

For a scanning worm, $R_0$ factors, roughly, into

Every historically successful defense is an attack on one of these terms. Patching shrinks the susceptible fraction $S/N$. Firewalls and segmentation cut the effective scan rate $\beta$ by making most of the address space unreachable. Detection and remediation shorten the infectious lifetime $\tau$. Credential hygiene lowers the per-contact success $p$ for credential-spreading worms. Push any of these hard enough and $R_0$ crosses below 1, and the outbreak collapses on its own.

The crucial historical fact is that the $p$ and $S/N$ terms are coupled to a fixed exploit set. A traditional worm carries a finite library of vulnerabilities. Once those specific vulnerabilities are patched, $S/N$ collapses toward zero for that worm, and no amount of scanning speed can rescue $R_0$. This is why worms become obsolete: not because they are detected, but because the vulnerable population they can reproduce into disappears. The exploit is a depleting resource.

Stealth: attacking the infectious-lifetime term

There is a second term in $R_0$ that defenders can be forced to concede, and it is the one the How to 0wn the Internet paper is really about: the infectious lifetime $\tau$. A worm stays infectious only until it is noticed and remediated. Everything a worm does to avoid being noticed is, in the epidemiological accounting, an attack on $\tau$ — and $\tau$ multiplies $R_0$ just as directly as the exploit success $p$ does. This matters for the defensive argument because it is the term an adaptive adversary can push on without discovering a single new vulnerability.

It is worth being precise about why stealth is a lever, because the answer also hands defenders the counter. The reason Slammer burned out is instructive: it was maximally loud. Random-address scanning at bandwidth speed lights up every telescope, honeypot, and rate-based sensor on the internet, so $\tau$ was minutes — detection and filtering caught up almost as fast as it spread. Loud-and-fast maximizes the scan rate $\beta$ but minimizes $\tau$. Staniford, Paxson, and Weaver’s contribution was to point out, for defenders, that this trade-off is not fixed — that a worm could choose a very different point on the $\beta$–$\tau$ curve. Their taxonomy of quieter propagation strategies (formalized further in Weaver et al.’s A Taxonomy of Computer Worms, ACM WORM 2003) is worth stating at the conceptual level, because each one implies a specific place to look:

• Hit-list / pre-computed targeting. Instead of blind random scanning, the worm carries (or is seeded with) a list of known-reachable hosts, so it never emits the noisy reconnaissance sweep that betrays a random scanner. Detection surface: the list has to be built somewhere, sometime — the reconnaissance is displaced in time and place, not eliminated. Pre-attack scanning of your address space is itself a signal. (The theoretical top speed of such pre-seeded “flash” worms was worked out by Staniford et al., The Top Speed of Flash Worms, ACM WORM 2004.)
• Topological / contagion spread. Rather than scanning the address space at all, the worm propagates only along the host’s existing trust and communication paths — the address book, known_hosts, session logs, service-mesh neighbors. Its traffic rides channels that are supposed to carry traffic, so per-flow it looks legitimate. Staniford et al. call the limiting case a “contagion” worm — one that spreads entirely inside normal communication and never scans. Detection surface: it still perturbs the distribution — the timing, volume, and content of those legitimate channels shift, which is exactly what communication-graph and flow-anomaly detection is built to catch.
• Low-and-slow / sub-threshold pacing. Spread deliberately slowly, staying under whatever rate-based alarm the environment uses. Detection surface: this one is self-limiting, and that is the whole point below.

The Intelligent Worm angle here is the same thesis applied to a different term. In the static world, a worm author chooses a point on the $\beta$–$\tau$ curve at authoring time and is stuck with it. An onboard reasoning loop could instead pace itself adaptively — inferring the local detection posture and throttling its own propagation to whatever the environment appears to tolerate, turning stealth from a fixed authoring decision into a runtime-adaptive behavior, just as it turned the exploit from a fixed asset into an adaptive one. That is the version worth defending against.

But — and this is the reassuring part for defenders — stealth is not free in the $R_0$ arithmetic, and the trade-off is unforgiving. Every quiet strategy buys infectious lifetime $\tau$ by paying scan rate $\beta$, and $R_0$ is their product. A worm that paces itself below your detection threshold has, by definition, throttled its own reproductive rate; drive stealth far enough and $\beta$ falls until $R_0 < 1$ on its own. The adaptive pacer is negotiating against a floor it cannot see, and every increment of stealth moves it toward extinction from the other direction. The defensive implication is concrete: lowering your detection threshold is not just about catching the worm faster — it directly compresses the $\beta$ the attacker is allowed to use. A more sensitive behavioral sensor doesn’t merely shorten $\tau$; it shrinks the entire region of the $\beta$–$\tau$ curve where the worm can survive. That is why the countermeasure to stealth is not better signatures — a contagion worm has no distinctive signature — but behavioral and communication-graph anomaly detection, the same shift the rest of this essay keeps arriving at.

A history of static worms — and what each taught

The consistent pattern: worms exploit known, unpatched vulnerabilities far more often than novel ones. WannaCry’s exploit had a fix available before the outbreak. That single empirical regularity is why patch management is the highest-leverage defense in existence — it directly depletes $S/N$, the term the attacker cannot manufacture more of.

That last clause is the entire thesis of this essay. The attacker cannot manufacture more susceptible hosts — under the static assumption. The Intelligent Worm is a hypothesis about relaxing exactly that constraint.

The generational shift

Read as a progression, worm history is a story of where adaptation lives and who supplies it:

The jump that matters is between the second and third rows, and it is subtler than “the AI writes the exploits.” Modular worms already decouple propagation from exploitation — that’s not new. What is new is who closes the loop. In the modular generation, when defenders patch a vector, a human must observe the drop in effectiveness, discover a new vector, write a module, and push it. That human is the rate limiter, and it is also the thing defenders can target: disrupt the author, the tooling, the distribution channel, and the module supply dries up.

The Intelligent Worm’s claim is that the loop closes onboard: the program itself observes that a vector no longer works, reasons about the target it’s facing, proposes new candidate capabilities, and updates itself — with no human in the path. If that were fully realized, the exploit would stop being a depleting resource. $S/N$ would no longer collapse toward zero as defenders patch, because the worm would keep re-deriving the $p$ term against whatever remains.

Formally, the shift is from a fixed per-contact success probability $p$ to a time-varying, self-updating $p(t)$ that the adversary drives back up as defenders drive it down. The epidemic threshold stops being a one-time cliff the defender pushes the worm over and becomes a contested equilibrium. That is a genuinely different control problem, and it is the reason to take the thought experiment seriously even while doubting near-term feasibility.

The adaptive loop, at the architectural level

Stripped of offensive specifics, the proposed mechanism is an autonomous control loop — an OODA cycle, or if you prefer the robotics framing, a perception–planning–action loop — wrapped around the classic propagation engine:

        Observe target environment
                 ↓
        Model the environment
                 ↓
        Reason about potential weaknesses
                 ↓
        Generate candidate capabilities  ← reasoning engine (LLM + tools)
                 ↓
        Evaluate in a safe validation sandbox
                 ↓
        Select an effective capability
                 ↓
        Update the internal exploitation module
                 ↓
        Continue propagation logic  ─────┐
                 ↑                        │
                 └────────────────────────┘

The reasoning engine is where a large language model would sit — not as a magic exploit oracle, but as one component in a toolchain: interpreting protocols and binaries, ranking which surfaces look weak, generating hypotheses about exploitability, and planning what to probe next. The critical and easily-missed box is “evaluate in a safe validation sandbox.” An adaptive worm cannot trust its own generated code any more than the rest of us can trust an LLM’s first draft; without an onboard verification step it would mostly generate confident nonsense and announce its presence by crashing targets. Verification is not a detail here — it is the feasibility bottleneck, and, as we’ll see, it is also a defensive gift.

Biology gives a clean analogy, and it’s worth stating precisely so it isn’t overread. A traditional worm is a clonal organism: it reproduces without variation, and when the environment changes — patches deploy — the population declines because it cannot generate new traits. An adaptive worm is closer to an organism that can generate novel traits under selection pressure. This is an analogy for the dynamics, not a claim of literal biological evolution; there is no mutation-and-selection over generations, there is a reasoning loop producing candidate variation within a single lineage. But the epidemiological consequence rhymes: a pathogen that can vary its infection mechanism faster than the host population can immunize is a qualitatively harder containment problem than one that cannot.

The full capability stack — and the footprint each subsystem adds

The natural next question is what a maximally-capable version of this architecture would bundle, because a serious threat model has to reason about the whole system, not the propagation core in isolation. The productive way to do this — and the way that keeps it a defensive exercise rather than a design document — is to take each capability an adversary would want, place it in the $R_0$ framework, and then name the detection surface it necessarily creates. The recurring finding is the same one the rest of this essay keeps hitting: every capability that helps the worm reproduce is also a behavior that must execute, and behavior is the thing defenders can see. Capability and footprint grow together.

• Centralized exploit generation (offloaded to a GPU back end). The heaviest part of the adaptive loop — reasoning over captured binaries and protocols, running fuzzing and program analysis, synthesizing and validating candidate exploits — is exactly the part you would not run on a compromised endpoint. It is compute-hungry and noisy. The realistic design offloads it: infected hosts phone home with reconnaissance, a central GPU-backed service does the expensive generation-and-validation, and vetted exploit modules are pushed back down to swap out stale ones. This is the second-generation modular/C2 pattern with an AI generation stage behind it. Defensive read: this is good news for defenders, and it’s worth saying plainly. Offloading re-centralizes what the fully-autonomous fantasy tried to distribute. It creates a command-and-control dependency — a channel to detect, a set of endpoints to sinkhole, a chokepoint to disrupt. The WannaCry kill-switch lesson generalizes: a worm that depends on reaching central infrastructure has handed defenders a single point to attack. Full onboard autonomy avoids this but pays the feasibility costs in the next section; the two are in tension.
• Adaptive propagation pacing (keyed to host and network conditions). Rather than a fixed scan rate, the worm profiles where it is — link capacity, host performance, observed monitoring posture — and speeds up on a fat, unmonitored pipe while slowing to a crawl on a segment that looks instrumented. This is the $\beta$–$\tau$ pacing from the stealth section, now driven by live telemetry. Defensive read: the trade-off floor still binds — pacing down to evade detection throttles $\beta$ toward $R_0 < 1$ — and the profiling itself is behavior: a process sampling system performance counters and timing probes to infer a monitoring posture is anomalous activity a behavioral sensor can flag. Adaptive pacing also means the worm runs slower by design in exactly the environments defenders instrument most, which buys response time.
• Inter-worm coordination (avoiding double-infection). The Morris worm’s defining failure was the absence of an infection check: it re-infected hosts until it DoS’d them, which is how it got caught. A capable worm therefore wants an infection marker — a way to recognize an already-compromised host and skip it — and, in the fancier designs Staniford et al. describe (permutation scanning), a way to coordinate so instances don’t redundantly re-scan the same space. Defensive read: this is the cleanest defensive judo in the whole stack. An infection marker is a signature, and it can be inverted into a vaccine. If the worm avoids hosts bearing a particular mark, defenders can apply that mark to healthy hosts to immunize them — a technique with real historical precedent. The coordination channel is itself detectable, and the marker gives incident responders a cheap, reliable indicator of compromise to sweep for.
• Persistence and concealment (rootkit-class hiding). To extend infectious lifetime $\tau$, the worm wants to survive reboots and hide from the operator and from security tooling — the function of the rootkit class, whether at userland, kernel, boot, or hypervisor layer. Defensive read: concealment directly contradicts this essay’s central claim that behavior is what an adversary cannot vary away — so it’s worth being precise about why it doesn’t rescue the attacker. Hiding is not the absence of behavior; it is additional behavior. Tampering with the kernel, hooking system calls, or forging boot state are themselves detectable events — through integrity monitoring, hypervisor-assisted introspection, memory forensics, and above all a hardware root of trust (measured boot / attestation) that a software rootkit cannot forge. The deepest, most privileged rootkits are the ones that must touch the most sensitive machinery to install, which is exactly where the best sensors live. Concealment raises the cost of detection; it does not eliminate the surface.
• Cross-platform reach (Linux / macOS / Windows). A worm confined to one OS is confined to that slice of the susceptible population; portability — a payload that can target, or recompile itself for, multiple operating systems — raises the effective $S/N$ by widening the reachable host set. Defensive read: portability is bought with generality and bulk. Cross-platform code is larger, carries more of its own runtime, and cannot lean on OS-specific assumptions — all of which increase its observable footprint, not decrease it. And it doesn’t buy an escape from behavioral detection: the propagation, coordination, and persistence behaviors still fire on every platform, so a defense built on what the worm does rather than which binary it is covers all three at once. Heterogeneity is a defense in itself here — the same monitoring philosophy ports across the fleet even when the malware does.

The synthesis is the important part, and it cuts against reading the list as a shopping cart. Each capability the adversary adds is a subsystem that must act, and every action is a place to be seen. A worm with all five is not a stealthier worm; it is a worm with a larger aggregate behavioral signature — more channels, more probes, more tampering, more code — layered on top of a central dependency defenders can target. Sophistication and detectability are not opposites here. They grow together, and that is a fact the defense should exploit rather than fear.

Feasibility: taking the limits seriously

It would be intellectually dishonest to present this as a near-term capability, and overstating it actually weakens the defensive argument. So here is the sober assessment. A language model alone is not going to autonomously discover reliable zero-days and consistently produce working exploits against arbitrary targets. The binding constraints today are real:

• Hallucination and code reliability. Generated exploits are brittle; memory-corruption primitives in particular demand precision that current models do not reliably hit against unseen targets.
• Verification cost. Confirming an exploit works without triggering the crashes and anomalies that light up defensive monitoring is itself hard — and every validation attempt is potential noise.
• Limited autonomous experimentation. Iterating on a live target is loud and slow; iterating in a faithful sandbox requires reconstructing the target environment, which is often infeasible from a foothold.
• Long-horizon memory and planning. Maintaining coherent state across a multi-step campaign remains a weak point.

What the current research actually shows is more modest and more interesting than “AI writes worms.” Several results establish that LLM agents — models wrapped in tool-use scaffolding, not raw models — can perform pieces of the offensive chain under favorable conditions:

• Morris II (Cohen, Bitton & Nassi, 2024) demonstrated self-replicating adversarial prompts that propagate through GenAI-powered application ecosystems — a worm whose medium is prompt-injection against AI assistants rather than memory corruption against services. This is the closest existing proof-of-concept to the “AI-native worm” idea, and notably it sidesteps the hardest part (reliable binary exploitation) by attacking the AI layer directly. It builds on the indirect-prompt-injection mechanism established by Greshake et al. (2023); related work shows such prompts self-replicating across multi-agent systems (Prompt Infection, 2024).
• The Fang et al. line of work argued that LLM agents can autonomously hack websites (2024), exploit one-day vulnerabilities from CVE descriptions (2024), and, in teams, make progress on zero-day-style tasks (2024). These results are real and also heavily caveated — success rates depend on generous scaffolding, known vulnerability classes, and web-application targets, not arbitrary network services.
• A parallel line builds and benchmarks LLM penetration-testing agents — early studies like Happe & Cito (2023), then structured frameworks such as PentestGPT, EnIGMA, and HackSynth — which measure how far tool-augmented agents get on CTF-style targets, and consistently find that interactive tooling, not raw model scale, is what moves the needle.
• On the defensive and dual-use side, Google’s Big Sleep project reported an LLM agent finding a previously unknown memory-safety bug in SQLite in 2024, and DARPA’s AI Cyber Challenge pushed automated vuln-finding-and-patching systems to the DEF CON finals. The same reasoning-over-code capability cuts both ways.

The honest synthesis: a realistic future adaptive system would not be an LLM by itself. It would be an LLM orchestrating the mature machinery of program analysis — fuzzing, symbolic execution, static analysis, dynamic instrumentation, automated test generation (ML has been applied across this pipeline for years — e.g. neural-guided fuzzing, NEUZZ, surveyed by Saavedra et al. 2019 — though the gains are contested enough that careful re-evaluations find them smaller than first reported) — using the model for the parts those tools are bad at (hypothesis formation, cross-domain reasoning, planning) and delegating verification to tools that don’t hallucinate. That hybrid is the thing worth defending against, and it is the thing worth designing defenses for now, before it exists in the wild.

The defensive re-architecture

Here is the payoff, and the reason to write this at all. If you accept that the exploit term can become adaptive — even partially, even hybrid — then the defensive posture built around static malware is aiming at the wrong invariant. Signatures describe a fixed artifact; an adaptive adversary changes the artifact. The defensive center of gravity has to shift from what the malware is to what it does, because behavior is the part it cannot fully vary away.

Concretely, the threat model points at a specific re-prioritization:

• Behavior-based over signature-based detection. You cannot enumerate the signatures of an adversary that regenerates itself. But the behaviors — mass scanning, lateral movement, anomalous process trees, novel binaries spawning network listeners, and above all the worm’s own validation/experimentation activity — are far harder to disguise. The noisy “evaluate in a sandbox” step is a detection surface. Detectors aimed specifically at self-propagating malware already work this way: unsupervised port-level network profiling (PORTFILER) flags worm-like traffic early, and the reachability structure of the network itself governs how far an outbreak gets (Chernikova et al. 2022) — a reminder that architecture is a detector too. Even the older signature-generation defenses have been analyzed for how fast they can converge to contain a novel worm (Valizadeh & van Dijk 2019).
• Runtime isolation and least privilege. Shrink what a foothold can reach and reason about. An adaptive worm that can’t observe or touch new subnets can’t drive its $p(t)$ back up — you’re attacking $\beta$ directly, and $\beta$ is not something the reasoning loop can manufacture.
• Aggressive network segmentation and egress filtering. These bound the reachable target set (holding down $S/N$ structurally, independent of patching) and throttle the exponential curve even mid-outbreak. Against a contested-threshold adversary, structural limits matter more than they did against a one-shot exploit.
• Rapid patch pipelines. Still the highest-leverage lever — but the tempo requirement changes. Against a static worm, patching eventually wins as $S/N$ decays. Against an adaptive one, patch latency becomes a live variable in a race, not a countdown that always terminates in the defender’s favor.
• AI-assisted defensive agents. The clean symmetry: the same autonomous reasoning that could drive adaptive offense is available to the defender for continuous monitoring, anomaly triage, and automated remediation. DARPA’s AIxCC is a bet that automated find-and-patch can run ahead of automated find-and-exploit. Whether defense or offense benefits more from AI is the open empirical question of this decade.
• Kill switches and circuit breakers. WannaCry was halted by a domain-based kill switch a researcher registered. Designing deliberate circuit breakers — rate caps, quarantine triggers, automated network fuses — is cheap insurance against fast-moving self-propagation.

The unifying observation: against a static adversary, defense is about detecting a known thing; against an adaptive one, defense is about denying the conditions the adaptation depends on — reachability, privilege, time, and undetected experimentation. Those conditions are architectural, and they are things we can build before the threat matures.

How buildable is this today — and what would it risk?

It helps to separate the two questions the previous sections have been circling: how much of this could an adversary build today, and what would it actually risk if they did. On buildability, the honest answer is uncomfortable but not alarming. Four of the five capabilities in the stack are decades-old, well-understood, and available off the shelf: the propagation engine, command-and-control with module-swapping, cross-platform payloads, and rootkit-class persistence are solved problems that ordinary malware has shipped for years. The single component that does not exist today is the load-bearing one — an onboard system that can reliably discover vulnerabilities and synthesize working, self-verified exploits against arbitrary unseen targets. That is the whole novelty of the Intelligent Worm, and by the feasibility assessment above it is exactly the part current AI cannot do dependably. A fully autonomous Intelligent Worm is therefore not buildable today.

But “not the fully autonomous version” is a thinner reassurance than it sounds, because the interesting risk lives in the partial cases. A hybrid worm — classic propagation with exploit generation offloaded to human-supervised, GPU-backed infrastructure, and LLM agents doing the reconnaissance and one-day exploitation that the Fang et al. results already demonstrate — is much closer to feasible, and it captures most of the adaptive advantage while keeping a human in the slow loop. Nearer still is the AI-native worm: the Morris II class of self-replicating prompt-injection attacks sidesteps binary exploitation entirely by targeting the AI application layer, and that layer is being wired into more of the internet every quarter. The most immediate propagation risk is not a memory-corruption worm reasoning about network protocols; it is a worm that spreads through agentic AI systems that were themselves built to follow instructions.

What would it risk? The historical worms bound the answer from two directions. Slammer showed the speed ceiling — near-bandwidth saturation of the vulnerable population in about ten minutes — but it burned out fast because it was loud and single-vector. An adaptive worm inverts that trade-off: it would likely be slower by design (pacing itself to survive) but far more persistent, because a self-updating exploitation term resists the patch-driven decay that eventually starves every static worm. The systemic ingredients that would make it dangerous are the ones that already make the internet fragile: software monoculture (one vulnerability reaching a huge susceptible fraction), flat and over-privileged networks, slow patch tempo, and — increasingly — homogeneous AI-agent deployments that share the same promptable weaknesses. The tail risk is not a faster Slammer; it is a quiet, persistent, multi-platform infection that a signature-centric defense never characterizes and so never fully clears.

None of this is a forecast that it is coming, and the essay’s central finding cuts the other way: every capability such a worm would need is also a behavior a defender can see, and the more of them it stacks, the larger its footprint grows. The risk is real, conditional, and — crucially — manageable if the defensive shift happens first. Signature-centric detection and patch-eventually-wins degrade against this adversary; behavior-centric detection, structural isolation, hardware roots of trust, and autonomous defense all become more central. Those are things we can build now, before the adaptive adversary is buildable. That is what a threat model is for: not to predict the attack, but to be ready for the class of attack before it arrives.

References

Everything below is public academic literature. arXiv identifiers link to the abstract page.

Epidemiological modeling of malware propagation

• W. O. Kermack and A. G. McKendrick, “A Contribution to the Mathematical Theory of Epidemics,” Proc. Royal Society A, 1927. — Origin of the SIR model and the reproductive number $R_0$.
• J. O. Kephart and S. R. White, “Directed-Graph Epidemiological Models of Computer Viruses,” IEEE S&P, 1991. — First mapping of biological epidemic models onto computer-virus spread.
• A. Chernikova, N. Gozzi, S. Boboila, N. Perra, T. Eliassi-Rad, A. Oprea, “Modeling Self-Propagating Malware with Epidemiological Models,” 2022. arXiv:2208.03276 — The SIIDR compartmental model; derives $R_0$ and fits fifteen real WannaCry traces.
• C. C. Zou, W. Gong, D. Towsley, “Code Red Worm Propagation Modeling and Analysis,” ACM CCS, 2002; and Zou, Towsley, Gong, “On the performance of Internet worm scanning strategies,” Performance Evaluation, 2006.
• S. Pappu et al., “Understanding Malware Propagation Dynamics through Scientific Machine Learning,” 2025. arXiv:2507.07143 — Neural-ODE / universal-differential-equation approach to learning propagation dynamics.

Worm history, taxonomy, and propagation strategy

• S. Staniford, V. Paxson, N. Weaver, “How to 0wn the Internet in Your Spare Time,” USENIX Security, 2002. — Hit-list, permutation, and topological/contagion scanning strategies.
• D. Moore et al., “Inside the Slammer Worm,” IEEE Security & Privacy, 2003. — Empirical analysis of the fastest random-scanning worm.
• D. Moore, C. Shannon, k. claffy, “Code-Red: a case study on the spread and victims of an Internet worm,” ACM IMW, 2002.
• N. Weaver, V. Paxson, S. Staniford, R. Cunningham, “A Taxonomy of Computer Worms,” ACM WORM, 2003. — The canonical worm taxonomy.
• S. Staniford, D. Moore, V. Paxson, N. Weaver, “The Top Speed of Flash Worms,” ACM WORM, 2004.

Detection and containment of self-propagating malware

• T. Ongun et al., “PORTFILER: Port-Level Network Profiling for Self-Propagating Malware Detection,” 2021. arXiv:2112.13798
• A. Chernikova et al., “Cyber Network Resilience against Self-Propagating Malware Attacks,” 2022. arXiv:2206.13594
• H. Valizadeh, M. van Dijk, “On the Convergence Rates of Learning-based Signature Generation Schemes to Contain Self-propagating Malware,” 2019. arXiv:1905.00154
• J. Saxe, K. Berlin, “Deep Neural Network Based Malware Detection Using Two Dimensional Binary Program Features,” 2015. arXiv:1508.03096

LLM agents for autonomous vulnerability discovery, exploitation, and pentesting

• R. Fang, R. Bindu, A. Gupta, Q. Zhan, D. Kang, “LLM Agents can Autonomously Hack Websites,” 2024. arXiv:2402.06664
• R. Fang, R. Bindu, A. Gupta, D. Kang, “LLM Agents can Autonomously Exploit One-day Vulnerabilities,” 2024. arXiv:2404.08144
• Zhu et al., “Teams of LLM Agents can Exploit Zero-Day Vulnerabilities,” 2024. arXiv:2406.01637
• A. Happe, J. Cito, “Getting pwn’d by AI: Penetration Testing with Large Language Models,” 2023. arXiv:2308.00121
• G. Deng et al., “PentestGPT: An LLM-empowered Automatic Penetration Testing Tool,” 2023. arXiv:2308.06782
• T. Abramovich et al., “EnIGMA: Interactive Tools Substantially Assist LM Agents in Finding Security Vulnerabilities,” 2024. arXiv:2409.16165
• L. Muzsai, D. Imolai, A. Lukács, “HackSynth: LLM Agent and Evaluation Framework for Autonomous Penetration Testing,” 2024. arXiv:2412.01778

AI-driven and self-replicating malware (prompt-injection worms)

• S. Cohen, R. Bitton, B. Nassi, “Here Comes The AI Worm: Unleashing Zero-click Worms that Target GenAI-Powered Applications” (Morris II), 2024. arXiv:2403.02817
• K. Greshake et al., “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection,” 2023. arXiv:2302.12173
• D. Lee, M. Tiwari, “Prompt Infection: LLM-to-LLM Prompt Injection within Multi-Agent Systems,” 2024. arXiv:2410.07283

ML-driven fuzzing and program analysis

• D. She et al., “NEUZZ: Efficient Fuzzing with Neural Program Smoothing,” 2018. arXiv:1807.05620
• M. Nicolae, K. Eisele, A. Zeller, “Revisiting Neural Program Smoothing for Fuzzing,” 2023. arXiv:2309.16618 — A contrarian re-evaluation.
• G. Saavedra, K. Rodhouse, D. Dunlavy, P. Kegelmeyer, “A Review of Machine Learning Applications in Fuzzing,” 2019. arXiv:1906.11133