What makes this worm different from prior AI-assisted malware research?

Previous research, including Morris II (2025) and ClawWorm (March 2026), showed AI spreading through AI application layers via prompt injection or RAG manipulation. The Toronto worm is different in kind: the LLM is not the attack target, it is the attack engine. It uses a locally hosted open-weight model to reason about and compromise ordinary network infrastructure — Linux servers, Windows hosts, IoT devices — in the same way a skilled attacker would, but autonomously and at machine speed.

Why does using a local open-weight model matter for defenders?

Commercial AI API providers can rate-limit, revoke access, or flag suspicious usage patterns. A worm that runs its own LLM on a local GPU — or on compute captured from victim machines — has no external dependency that defenders or platforms can sever. There is no API call to block. The reasoning capability travels with the worm and scales with the GPU resources it can capture from compromised hosts.

How should security teams respond to this research?

The prototype itself is not publicly released and the researchers have established a vetting process for defensive access. The operational priority is the reasoning it enables: any flat network where a single host with a GPU can be compromised should be treated as potentially able to serve as a reasoning node for automated lateral movement. Network segmentation, API and service exposure reduction, and runtime behavioural detection for systematic service enumeration are the relevant controls.

Self-Replicating AI Worm Uses Local LLM to Spread Across Networks

University of Toronto researchers have built a proof-of-concept AI worm that uses a locally hosted open-weight large language model to reason its way through a network, write custom exploits for whatever services it encounters, and replicate itself — all without touching a commercial AI API or receiving further human instruction. The preprint landed on arXiv on June 2 and is currently under peer review. The results are not comfortable reading.

Across 15 isolated test runs on a 33-host network, the worm gained elevated access on an average of 23.1 hosts and replicated to 20.4 of them — 62% of the network — over seven days, with no prior knowledge of network topology and no human input after deployment. It also exploited vulnerabilities disclosed after the model’s training cutoff by ingesting public advisory text at runtime, successfully rooting fresh hosts 41 of 67 times when tested against three post-cutoff CVEs.

What the Worm Actually Does

Traditional worms carry a fixed exploit payload chosen at build time. Patch those bugs, and propagation stops.

This one works differently. It uses an open-weight LLM running on a GPU to generate attack logic at runtime, tailored to whatever it finds on the next target. The process is: enumerate exposed services, query a local model for likely vulnerabilities and exploit approaches, attempt exploitation, extract credentials and configuration data from compromised hosts, then repeat. No pre-encoded exploit chain. No dependency on a provider that could be rate-limited or have access revoked.

The exploit set across a single representative run included SambaCry, Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim RCE, blind SQL injection, JWT bypass, Redis escape, and a writable root cron privilege escalation — not because they were pre-programmed, but because the model reasoned its way to them from what it found on each host.

The test environment (nicknamed “FakeCorp”) spanned Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019 and 2022, and IoT devices. Each host had at least one real-world vulnerability. Five of the 33 machines had GPUs.

The Local Compute Problem

The feature most worth noting for defenders is the GPU tier. Infected GPU-capable hosts can serve as distributed reasoning nodes, providing inference for lower-compute machines on the network that cannot run the model themselves.

The paper separately tested full GPU-tier replication, where the worm stages a local LLM instance on a compromised GPU host. That succeeded in 68.8% of attempts. In a network that contains a few GPU-capable machines — a realistic assumption for any organisation running ML workloads, rendering, simulation, or even high-end workstations — a single successful GPU compromise turns into a local inference pool for the rest of the spread.

This is why commercial API reliance was a meaningful constraint in earlier AI-assisted attack research. An attacker using OpenAI’s API to drive lateral movement can be cut off. A worm that has staged a model on a compromised GPU cannot be. The reasoning capability is now inside the network perimeter.

The Patch Gap Problem, Restated

The most operationally significant finding is not the propagation rate. It is the runtime advisory ingestion.

CVE-2026-39987 was publicly disclosed on April 8, 2026. Sysdig observed exploitation in honeypots 9 hours and 41 minutes later. The Toronto worm exploited that same vulnerability in test conditions, having read the public advisory at runtime. This collapses the time between public disclosure and automated exploitation to roughly as long as it takes to fetch an advisory text file.

The relevant frame here is WannaCry. EternalBlue had been patched for months before WannaCry hit. The damage came from the patch gap — the window between fix availability and fix deployment. An adaptive worm can keep testing new paths during that window, and can read fresh advisories as they drop. Patch Tuesday creates a predictable schedule of new targets for a system of this kind.

What This Is Not

The paper is clear about the limitations of the prototype. The test environment was deliberately vulnerable and isolated, with no active endpoint defence, no network segmentation beyond what individual hosts provided, and no SOC monitoring that would intervene. Individual exploit attempts succeeded about 44% of the time, with most failures coming from malformed payload syntax. Web application exploits and Windows privilege escalation were notably harder than Linux local privilege escalation.

The worm also has no stealth features. No encryption of command traffic, no polymorphic code, no persistence mechanisms beyond replication, no log cleanup. A real deployment would need these to avoid detection on hardened networks. The paper treats this as scope, not as a structural defence: the stealth layer is tractable engineering, not a fundamental barrier.

The implementation is not publicly released. The CleverHans Lab, led by associate professor Nicolas Papernot and spanning Toronto, Vector Institute, Cambridge, and ServiceNow, is establishing a vetting process for qualified defensive researchers.

Context: Where This Sits

ClawWorm (March 2026) demonstrated self-replication across LLM agent ecosystems — AI attacking AI infrastructure. Morris II (Cohen et al., 2025) showed adversarial prompts spreading through RAG-enabled email assistants. The Toronto worm sits in a different category: it is an AI attacking ordinary host infrastructure, using the LLM the same way a skilled penetration tester uses knowledge and reasoning, but autonomously and without sleep or attention limits.

The real-world parallel the paper cites is Anthropic’s November 2025 disclosure: a Chinese state-sponsored operation (GTG-1002) in which Claude Code handled 80-90% of an intrusion, including reconnaissance, exploit development, lateral movement, and exfiltration. The Toronto paper is the lab version of that direction pushed into worm propagation.

The direction of travel is not ambiguous. Less human input per intrusion, more delegation to the model, and progressively lower cost per compromised host.