AI worms already exist in the lab. In 2024, researchers demonstrated Morris II, a worm that spread between generative AI email assistants by hiding self-replicating prompts in the messages they processed. In June 2026, a University of Toronto team described an AI agent worm that built a tailored attack for each machine it found and ran open-weight models on the computers it compromised, across Linux, Windows and IoT devices.
Research published by Anthropic on 12 October takes that idea to the cheapest hardware on the network. It examines a worm that carries its own model weights and runs them on internet-of-things devices, with no data centre and no commercial AI service behind it. The results suggest that the hardest new step, getting a model running on a device it has never seen, is already within reach of small models on most of the hardware types the researchers tried.
That marks a real shift. Mirai, the IoT botnet that disrupted major online services in 2016, broke into devices by working through a list of default usernames and passwords, and its authors built separate versions for each chip type they wanted to reach. Scripts like Mirai’s can handle the failures their authors anticipated. A model can attempt the ones nobody anticipated.
What Anthropic tested
Anthropic’s Frontier Red Team ran three separate experiments, and each one shows something different.
The first tested inference setup on real hardware. Open-weight models were given access to nine types of device, from Nvidia Jetson Nano boards to Mac computers and RTX 4090 graphics cards, and asked to get a model server running Meta’s Llama 3.1 8B. The prompt told each model what hardware it was on. Alibaba’s Qwen3.5-9B, a model small enough to run on a laptop, succeeded on eight of the nine.
The second tested the full replication cycle on eight emulated Android devices, each with an unauthenticated debug port. Zhipu AI’s GLM-5.2 ran on its own server, found each device, connected to it and installed the smaller Llama 3.1 8B model there. It reached all eight devices in four of five trials and seven in the fifth. GLM-5.2 was the only open-weight model in Anthropic’s set to complete the cycle, and the report says GLM-5.2 and stronger models can do so in its simplified evaluation. Because the break-in step was kept deliberately trivial, the researchers describe the result as an upper bound on real-world success.
The third showed capacity. Anthropic bought 15 off-the-shelf Android TV boxes at about $55 each, each with 4GB of memory, and split Google’s 26-billion-parameter Gemma 4 model across them. Together they ran it at 0.39 tokens per second. Nothing broke into those boxes; the demonstration measured whether cheap hardware could hold a capable model at all. By Anthropic’s own sizing, even a 9-billion-parameter model compressed to 4 bits needs four or more such boxes.
In every experiment the models worked under instructions to replicate inside a task harness, so the results show what a model can do once ordered to spread. Anthropic states plainly that no full rogue replicator exists yet. Its projection that a model under 30 billion parameters could reach GLM-5.2’s level by the end of 2026 rests on a gain of 13.7 points a year on the Epoch Capabilities Index, which the report itself calls only a proxy for replication ability. For security teams, that makes this a near-term planning problem, and the controls that blunt it are ones most organisations already own.
How a weight-based worm would work
Anthropic breaks the cycle into four steps: find a device, break in, set up a model there, and repeat from the new host. The first two are familiar from every botnet of the past decade. The third is new. Mirai carried a password list. A weight-based worm carries a model, and its novel work begins after the break-in, when it installs an inference engine, the software that runs a model, on the device it has just entered. That means choosing a compatible software stack, finding the right package versions and debugging faults specific to that machine.
Cheap devices can only hold small models, so the scenario centres on open-weight models of 30 billion parameters or fewer, files anyone can download and run. Today those models complete many of the individual steps and make mistakes when chaining them end to end. Copies can also pass on what they have learned. In one test, each Qwen instance left brief notes for the next on what it had tried, and the success rate for setting up inference rose from 45% in the first generation to between 61% and 84% in later ones. The model itself never changed; the notes carried the improvement. Giving the small model a far stronger frontier model as an adviser made no measurable difference, because it did not know which questions to ask.
How it would reach a corporate network
Anthropic names home and small-business devices as the likely first targets, led by off-brand Android TV boxes, and the route into a business may be a box someone carries through the front door. The Kimwolf botnet compromised more than two million devices, mostly unofficial Android TV boxes and set-top boxes, largely through an exposed Android Debug Bridge (ADB), a developer tool that, left open, hands out remote command execution. Synthient found boxes that shipped with residential proxy software already installed, and KrebsOnSecurity reported that Kimwolf’s operators sent commands through those proxies to scan for and infect other vulnerable devices on each box’s local network. Residential proxies of that kind already sit inside organisations: Spur found them on nearly 300 government networks, 318 utilities and 166 healthcare organisations. Plug a box like that into a breakroom TV and the same door opens at work.
The second tier of targets matters more to the enterprise. Security cameras and video-conferencing units increasingly ship with small built-in AI chips designed to run models on the device itself, and Anthropic expects that extra computing power to make them attractive targets too. Its estimate puts roughly 9.5 million fielded units across around 90 Nvidia-silicon IoT product lines, though most connect outward through cloud management tunnels and are not directly reachable from the internet. In my experience, these are the devices that sit in meeting rooms, reception areas and branch offices, and they rarely appear in a security team’s asset register with any detail about the software they run.
What it would mean for a business
A working AI worm would turn a company’s unmanaged devices into attack hosts. The compute it could harvest is modest. By Anthropic’s rough estimate, a Kimwolf-sized fleet of two million TV boxes adds up to at most about 40 Nvidia H100 data-centre GPUs’ worth of inference, a figure the report anchors on a single hardware class. The concern is a replicator that can survive without a central AI service. With no API provider to cut it off and no single point to shut down, safeguards such as refusals and rate limits never come into play, a point the Toronto team also makes. On Anthropic’s numbers, such a worm on cheap hardware doubles in days. Inference engines can run without administrator privileges, and many low-end devices can be reinfected as soon as they restart, so a device that reboots clean stays exposed until someone closes the port the worm came through.
For most organisations the cost will show up as cleanup: isolating devices, then patching or replacing hardware that often has no patch to apply. That work will begin at branch offices and other sites with the thinnest security staffing. It also exposes a familiar supply chain gap. Many of these appliances run vendor forks of open-source operating systems that the manufacturer has never hardened and may never update. If you cannot say what software and firmware a conference-room display is running, or whether its maker still supports it, you cannot judge whether it will ever receive a fix.
The defender’s advantage
Some of the physics favours the defender. Conventional bots are small files. A worm that carries its own model moves gigabytes to spread, and a model split across several devices keeps those devices talking to each other for long periods. Anthropic names those multi-gigabyte transfers, and sustained device-to-device traffic between machines that would not normally exchange data, as the signals to watch. Traffic like that justifies an investigation, though it will not flag every case. Anthropic notes that a worm could re-download its model from a public hub, and a download from a site such as Hugging Face looks like ordinary web traffic.
History also shows that containment works. When one ISP quarantined Mirai-infected customers, restricting their connections to a short list of permitted sites and directing them to cleanup instructions, 92% of infections were cleared within 14 days. In comparison groups whose users were not quarantined or notified, between 58% and 74% of infections cleared naturally. Regulation is shrinking the pool of easy targets as well. In the UK, default passwords on consumer smart devices are no longer permitted. Anthropic frames the goal in epidemiological terms: push the number of new devices each infected device goes on to infect below one, and the outbreak dies out.
Where security leaders should start
Start with the devices that cannot run security software, from conference-room displays to cameras. An AI worm adapts to whatever device it reaches, so the most reliable control is limiting which devices it can reach and what it can fetch once there.
- Segment by permitted behaviour. Give each unmanaged device a written list of the connections it is allowed to make and deny everything else. NIST’s SP 1800-15 guidance on Manufacturer Usage Description shows how to restrict an IoT device to only the traffic it needs for its intended function.
- Close the debug doors. Inventory every Android-based appliance, including displays, TV boxes, kiosks and video-conferencing units, and find any debugging service that answers over the network, starting with ADB on TCP port 5555. Disable each one outside maintenance windows and keep unofficial TV boxes off the corporate network altogether. Anthropic’s test worm paired new AI with Kimwolf’s old route in: an open Android debug port.
- Know what is running on them. Record the operating system, firmware version and vendor support status for each device, so that when an incident comes you already know which ones can be patched and which must be replaced.
- Cut off the model supply. Block devices that cannot run security software from reaching public model download sites such as Hugging Face. A weight-based worm needs its weights, and a display or camera has no reason to fetch them.
- Watch the traffic and pre-approve the response. Alert when a device with no security software pulls a gigabyte-scale transfer from a peer device or an unapproved host or holds sustained traffic with another such device. Agree the playbook in advance: investigate, quarantine when the traffic has no business explanation, then reimage or replace devices with no vendor fix.
Leave unmanaged devices on a flat network with a debug port answering, and you hand any self-spreading worm its path from one device to the next. When two conference-room displays start trading gigabytes, send an investigator.
