The AI worm moved its inference bill onto the victim

An AI-driven worm reached half of a 33-host lab network in roughly five days. It did not call a frontier-model API. It ran an unnamed open-weight model on compromised GPU machines, then let smaller infected devices send their reasoning work back to that stolen compute.

The June 2 preprint calls the attacker's marginal cost for each new infection zero. That is the sentence security teams should keep—but read it literally. The inference bill did not disappear. It moved onto the victim's machines, where the cost transfer can become a detection signal.

This is not an argument that a GPU alert stops an adaptive worm. The experiment deliberately omitted stealth, used a flat network in which every target had an exploitable weakness, and ran without endpoint detection, antivirus or active host firewalls. It is a narrower operating claim: if the threat needs sustained reasoning, defenders should instrument the place that reasoning is paid for, then compare their detection time with the worm's propagation time.

The headline is capability; the result is economics

The research team—across the University of Toronto, Vector Institute, University of Cambridge and ServiceNow—ran 15 independent seven-day experiments. Each began with one attacker machine inside a contained virtual network spanning Linux, Windows and simulated IoT devices. Five of the 33 targets represented GPU hosts.

The model was publicly available, released in 2025 and small enough to fit on one 80GB A100. The authors withheld its identity and parts of the harness for dual-use reasons. They did not fine-tune it. Instead, the harness supplied relevant guidance and retrieved public vulnerability information when the model needed context.

On average, the system identified 31.3 vulnerabilities, gained elevated access on 23.1 hosts and launched replicas on 20.4. It reached as many as seven generations of replication. Individual exploitation attempts were much shakier—44% succeeded—and malformed payloads caused many failures. Once exploitation succeeded, a specialised deployment layer helped replicas launch 88% of the time.

That combination matters. The model did not need to be consistently brilliant. A distributed system could keep trying, share information and redirect reasoning requests to surviving GPU nodes. Capability thresholds ask whether one model can complete one attack chain. The worm's economics ask how cheaply a fragile attempt can be repeated after the first foothold.

Zero marginal cost leaves a meter running

The paper's attacker-cost claim is directionally strong and easy to misuse. “Zero” does not mean the campaign consumes no resources. It means the attacker is no longer paying the incremental compute bill. The compromised organisation is.

That creates a defensive asymmetry of its own. In this architecture, a GPU host has to run the local model or serve reasoning to other replicas. The paper reports hundreds of inference calls per target for reconnaissance, strategy and generation. Reaching half the network took about five days—far slower than a classic worm replaying fixed exploit code at network speed.

rendering diagram…

My proposed metric is time to unexplained inference: how long from a new model-serving workload, sustained accelerator use or unusual internal inference traffic to a triaged security event? Put that beside time to isolate the segment and time to deploy a verified patch. The paper measured the attack clock. A defender needs to measure whether its own clock is shorter.

Those signals are hypotheses to test, not signatures validated by this study. The prototype did not try to hide its local compute, encrypted traffic or forensic artefacts. A real adversary could disguise processes, shift reasoning elsewhere or deliberately stay below a utilisation threshold. Alerting on every legitimate model job would bury the signal just as effectively.

So baseline first. Inventory authorised model servers and accelerator jobs. Then test whether monitoring can distinguish a new unauthorised runtime, an unexpected jump in model-serving duty cycle, or one machine suddenly answering inference-like requests for peers. Correlate resource telemetry with identity, process and network events; a watt or VRAM threshold alone has no idea whether the work is malicious.

The patch clock still decides the outcome

The paper is unusually sober about defence. Its five-day half-network result gives operators more time than a fixed-exploit worm would. The authors point to micro-segmentation, continuous authorisation, reduced dependency surface, automated vulnerability verification and faster patch verification. Their FakeCorp network was intentionally flat, so the study does not show the same spread through a hardened enterprise.

That caveat changes the practical takeaway. Do not build an “AI worm detector” and imagine the class is handled. Make lateral movement expensive, remove exposed weaknesses and rehearse isolation. Compute telemetry is an early-warning layer for the paper's demonstrated architecture, not a replacement for ordinary network security.

In July I argued that agent-speed attacks create agent-speed evidence when every action is recorded. This paper adds a physical version of the same idea: parasitic reasoning creates resource activity somewhere. And because an adaptive attacker can rewrite individual payloads, the loop remains a better detection unit than the file.

Steal this for the next cyber-capability review. Alongside “which model can do this?”, ask who pays for each attempt, where that consumption appears, how quickly you can detect it, and whether segmentation plus patching can beat the measured propagation window. A capability tier tells you what a model might attempt. The meter tells you where the attempt is running.

When the worm moves its inference bill onto your machines, treat the bill as telemetry—and make your detection clock shorter than its spread.