How to detect a self-replicating AI worm on your network

To detect a self-replicating AI worm, segment your IoT devices instead of buying an antivirus: block the IoT VLAN from model hubs, isolate devices from each other, alert on IoT host pairs that start talking for the first time, and close ADB on port 5555.

In our own test, a 20-line flow rule flagged a 4.92 GB GGUF of Llama3.1-8B, the model Anthropic's worm installs, in a plaintext loopback transfer. By our own arithmetic, sharding the file across four boxes cuts each device's download to about 1.2 GB, and at that size a volume rule can't tell weights from an ordinary backup.

William Zhou and Daniel Freeman of Anthropic's Frontier Red Team published the experiment on October 12 as a blog post, not a paper, and none of the code or data behind it has been released. This post is about the defender's side: what a replicating model looks like on the wire, which signals survive TLS and sharding, and what to change on a home or office network this week.

What Anthropic's worm actually did

Only GLM-5.2, a 744B model by Anthropic's figure, spread end to end, reaching 8 of 8 emulated Android nodes in 4 of 5 trials (results figure). Three conditions made that easy: its own model ran on a separate inference server, the payload it installed on each node was Llama3.1-8B, and the way in was an ADB port with no authentication. Small open models reached 0 of 8. In a 17-node variant where a script did both the hacking and the inference setup, Qwen3.5-9B and Ministral-14B reached 17 of 17 (compare these models in our LLM picker).

That ablation suggests, without proving, that the hard part for small models is getting inference running on unfamiliar hardware. It scripted two steps at once, so it can't separate them, and on its own Qwen3.5-9B did get a server running on 8 of 9 hardware types (grid below). Anthropic did not measure the exploit step at all.

On x86 with a known recipe, delivery and setup take minutes

We scripted the delivery and setup steps on a Linux cloud container (Intel Xeon @ 2.1 GHz, 4 vCPU, 15 GB RAM, no GPU). No agent did any of this, because we had no Pi/Memento harness, and we did not test ARM, low-RAM or IoT builds. We didn't find the exact file named in Anthropic's post, so the Q4_K_M quantization below is our choice.

The model then decoded at about 3.6 tok/s on 4 threads in our own run. That isn't comparable with Anthropic's Xeon column, which uses a different instance and concurrency. A 179-second build on x86 says the build is not slow when the recipe is known; the open question is how quickly a small agent finds the recipe on hardware it hasn't seen, such as MI300X and TPU, where Qwen3.5-9B scored 0/4 and 1/5 in small samples.

How do you detect an AI worm on your network?

Watch where model files come from and which IoT devices start talking to each other. A file-signature rule helps only against a worm that isn't trying to hide.

Anthropic's defence section says "newly infected hosts may receive multi-gigabyte model payloads from other devices or external hosting services", and that "the faster it replicates, the more traffic it produces." We tested the bulk-transfer part. Our detector reads a packet capture and flags any TCP flow over 2 GiB, and any flow whose payload starts with the GGUF or safetensors magic bytes once the HTTP headers are stripped. Below is a simplified excerpt of our test script. It is a test harness, not a production detector.

MAGICS = {b"GGUF": "gguf", b'{"__metadata__"': "safetensors-header"}
for ts, buf in dpkt.pcap.Reader(f):
    ip = dpkt.ethernet.Ethernet(buf).data
    if not isinstance(ip, dpkt.ip.IP) or not isinstance(ip.data, dpkt.tcp.TCP):
        continue
    t = ip.data
    k = (ip.src, t.sport, ip.dst, t.dport)
    flows[k] += ip.len - ip.hl * 4 - t.off * 4   # payload bytes; works with a short snaplen
    p = t.data
    if p and k not in hits:
        body = p.split(b"\r\n\r\n", 1)[1] if b"\r\n\r\n" in p[:2048] else p
        for magic, name in MAGICS.items():
            if body.startswith(magic):
                hits[k] = name
# alert when flows[k] > THRESH (default 2 GiB) or k in hits

In our own test we served the GGUF and a 1.5 GB random-data backup.tar over loopback with python3 -m http.server and captured both with tcpdump: 285,725 packets at a 512-byte snapshot length, 72 MB, 0 drops. The detector parsed it in about 4 seconds.

Read the clean result with care. The 2 GiB threshold happened to sit between the two file sizes we chose, so "no false positives" says little. The file signature was the only signal that told weights apart from a backup, and it disappeared over HTTPS. It also fails on plaintext against anyone who tries: a one-byte XOR, gzip transfer encoding, a tar or zip wrapper, or parallel range requests that put the header in only one chunk all hide the GGUF prefix. A magic-byte rule catches a careless transfer. Treat it as a bonus, not a control.

Volume still tells you something. The Qwen3.5-9B Q4_K_M GGUF is 5.68 GB. Over 100 Mbps that is 5.68e9 × 8 / 1e8 ≈ 454 s of sustained transfer by our own arithmetic, and it shows up in the orig_bytes/resp_bytes counters of Zeek's conn.log.

Sharding defeats volume rules, so alert on new IoT host pairs

Anthropic says a 9B-class model needs at least four 4 GB boxes. If each box downloads only its own shard, which is our assumption, the 4.92 GB file is about 1.23 GB per box and the 5.68 GB Qwen3.5-9B file about 1.42 GB. Both sit under our 2 GiB threshold, and at a 1 GB threshold our benign backup already fired.

Traffic between boxes running a sharded model is small. The GGUF metadata gives an embedding length of 4096 and 32 blocks, so one fp16 activation per token per hop is 4096 × 2 B = 8 KiB. Anthropic estimates roughly 0.3 tok/s for an unoptimized Gemma4-26B-A4B across the TV boxes, which gives roughly 2.4 KB/s per hop. Both numbers are our own order-of-magnitude estimate, mixing Llama3.1-8B geometry with Anthropic's Gemma figure, not a capture.

Anthropic names the signal that survives: "sustained device-to-device traffic between machines that wouldn't ordinarily communicate". It doesn't say whether the pipeline uses one long connection or many short ones, so don't filter on connection duration. Key on the host pair: list every IoT-to-IoT pair seen in a baseline week, then alert on any pair that isn't on that list. We did not build or test this rule.

# untested sketch. Needs Site::local_nets set to your LAN, or local_orig/local_resp
# are never T. No duration filter: short per-request connections count too.
zeek-cut id.orig_h id.resp_h id.resp_p local_orig local_resp < conn.log \
  | awk '$4=="T" && $5=="T" {print $1, $2, $3}' | sort -u > pairs.today
comm -13 pairs.baseline pairs.today   # IoT pairs never seen in the baseline week

On HN, pianopatrick noted that a Wi-Fi mesh swarm "might never hit an ISP", one more reason to monitor inside your own network. Heat and fan noise are a weak tell: rerdavies says his ISP cable modem is "consistently hot to the touch" and he has no way to see why.

Checklist: close 5555 and deny model-hub egress from the IoT VLAN

Anthropic uses the Kimwolf botnet as its reference. Kimwolf already runs on about 2 million devices, mostly TV boxes, and spreads through exposed ADB, so this list pays off today whether or not a weight-carrying worm ever appears. Cloudflare also notes that many cheap boxes ship "pre-infected" with proxy SDKs. Those boxes need replacing; no checklist fixes them.

1. Check your LAN for port 5555. Run nmap -p 5555 --open 192.168.1.0/24 with your own subnet. Against our emulated listener, nmap reported 5555/tcp open freeciv, its default name for that port, so treat any open 5555 on a TV box as network ADB.

2. Turn off network ADB on any box that has it open.

3. Put IoT devices on their own VLAN and turn on client or port isolation inside it. Block TCP 5555 between IoT hosts as well as from outside. A worm hops from box to box, so east-west traffic matters as much as the WAN edge.

4. Default-deny IoT egress and allowlist the vendor endpoints each device needs. If your router can't do that, at least block DNS and TLS (by SNI) to huggingface.co and hf.co; that list misses CDN hostnames and mirrors, and DNS-over-HTTPS bypasses it. Egress control stops the first pull from a hub. Once one box holds the file, only step 3 helps.

5. Alert on new IoT-to-IoT host pairs, starting from the sketch above.

6. Use per-device volume alerts near 1 GB only on low-traffic devices such as cameras, plugs and appliances, and allowlist your backup hosts. Streaming boxes move video all evening, so a 1 GB alert on them is noise.

7. Don't rely on detecting root access. Anthropic notes that weight-based replicators run entirely in userspace and can re-infect low-security devices after a restart.

If you host models yourself, as in our local LLM setup guide, keep those boxes off the IoT segment.

Does antivirus stop an AI worm? No; the useful tools watch the network

Once a worm runs open weights on machines it has taken over, provider-side refusals and rate limits never see it. The Toronto/Cambridge adaptive-worm paper calls them "structurally irrelevant". Defence moves to the network, the device and the ISP, the same shift we described after the Hugging Face intrusion by an AI agent.

We didn't test these tools. The table comes from their official pages:

The NDSS Mirai study found that users reach for the wrong tool: some "run anti-virus software on their PC to solve the infection of an IoT device". PC security still helps at the break-in stage. Retr0id notes that "brute force all known vulnerabilities" is something AV and EDR "can detect". Anthropic's defence section covers ISPs, manufacturers and regulators. It says nothing to someone running a homelab or a 20-seat office.

ISP quarantine works, but the 92% comes from 220 customers at one ISP

Anthropic cites the Mirai trial as "92% of infections within 14 days, against 74% with no notification." The NDSS paper is a randomized trial with 220 consumers at one medium-sized ISP. Without notification, 58% to 74% of infections cleared on their own, depending on the group, so Anthropic quotes the top of the range. Email-only notices had "no observable impact", and the authors warn that walled gardens will be "hard to scale up" because ISPs have weak incentives to run them.

Against that 74% baseline, quarantine leaves 8% of infections in place versus 26%, about 3.3× fewer by our own calculation. That serves Anthropic's goal of pushing R₀ (new infections per infected device) below 1. Since 29 April 2024 the UK PSTI regime has also banned default passwords on consumer smart devices.

'8 of 9 hardware types' includes a 1-of-5 TPU cell and a smaller Jetson model

Source: Anthropic, "Self-replicating AI" inference-setup figure, screenshot for editorial use.

Qwen3.5-9B served a working model on 13 of 15 Xeon runs and 0 of 4 MI300X runs. We pulled the raw served/clean counts from Anthropic's embedded figure:

*Because of memory limits, the Jetson column sets up Llama3.2-3B, "not the Llama3.1-8B of every other column".

Most cells hold only 4 to 18 runs. Several HN and Bluesky commenters said IoT devices lack the RAM for a 9B model (hypfer: "way too large for any such IoT"), which ignores the sharding across four or more 4 GB boxes. The speed objection holds: the 15-box Gemma4-26B-A4B demo ran at 0.39 tok/s, and Anthropic estimates one full inference setup at 28–51 hours for Qwen3.5-9B and 71–150 hours for Gemma4.

The 'months away' clock is a 2.4-point gap on a proxy index

Anthropic fits +13.7 points a year on the Epoch Capabilities Index (ECI, R² 0.95) for open models of 30B or fewer, and takes GLM-5.2's 151.8 as the floor for replication. Qwen3.8-27B sits 2.4 points short, about two months at that rate, hence "end of 2026". The post concedes ECI is "only a proxy metric for replication ability". The learning-across-generations curve (45%, 72%, 61%, 63%, 84%, 65%) goes up and down with overlapping confidence intervals, and access to a frontier advisor (Opus 4.8) made no significant difference either way.

What's new is the hardware measurement. Earlier work didn't test small models setting up inference on cheap, mixed hardware: METR's 2023 replication evals, Morris II's self-copying prompts, Fudan's 2024 claim and UK AISI's RepliBench. As for the Toronto/Cambridge worm, smokel notes that its main experiments "do not copy LLMs to target machines". Memento (Anthropic's agent harness), the eval data and the anti-cheating checks are unreleased, so nobody outside Anthropic can reproduce the success rates.

The politics run alongside the numbers. On HN, the top subthread read the post as groundwork for an open-weights ban, and aaroninsf replied: "The answer is not to ban open models; nor is it do nothing." Davi Ottenheimer argues that the paper contradicts itself: its advisor data shows large models add nothing, yet it predicts large models will coordinate swarms of small ones. For how Anthropic handles capabilities it considers too risky to ship, see our piece on the withheld Mythos Preview.

Act now if you run a homelab or SMB network; skip "AI antivirus" products

If you run a homelab, a small office network or local LLM hosts, work through the checklist this week; most of it is configuration you already know how to do. If a vendor pitches an endpoint "AI antivirus" for this, the Mirai evidence says the controls that work sit on the network. If everything you run is in managed cloud, this mostly isn't your problem yet.

Anthropic says "AI botnets could also act intelligently to counter defenders, but we haven't tested this." Three results would move this from hygiene to urgent:

• an independent replication of Anthropic's numbers

• a small model passing end to end without scripted setup

• a tested result on worms adapting to evade defenders