AI Ported a Pre-Auth PLC Exploit for $535: Reading Forescout's WAGO Experiment

The interesting number in Forescout's latest research is not the CVSS score. It is $535.74. That is what it cost, in API usage, to have Claude port a working pre-authentication remote-code-execution exploit from one WAGO programmable logic controller to a different model — a device running an end-of-life real-time operating system that has no firmware fix and never will. The port took eight and a half hours of a session, most of it a human steering the model off dead ends. It ended with the AI writing ARM shellcode that phoned home over ICMP and UDP twelve minutes after it first ran code, and then, on a later unsupervised run, permanently bricking the controller by writing to flash.

None of that is science fiction, and — this is the part worth sitting with — none of it is even especially impressive yet. Forescout titled the writeup "Can AI Create PLC Attacks? Yes, But It's Not That Easy Yet", and the honesty is the point. A skilled human could have done this port faster today, without the model. What changed is the shape of the cost curve, and the cost curve is what defenders actually budget against.

What Forescout's Vedere Labs actually did

The target was CVE-2021-31886, a pre-authentication stack buffer overflow in the FTP server that ships with Siemens' Nucleus RTOS. The FTP service does not validate the length of the username sent in the USER command over TCP port 21; an oversized username overwrites the stack and lets an attacker redirect execution. Siemens assigned it a CVSS of 9.8. It is reachable before any login, and — because the affected Nucleus V1 devices are end-of-life — CERT@VDE's advisory lists no firmware update for a long tail of WAGO controllers: the 750-829, 750-831, 750-852, 750-881, 750-882, 750-885, 750-889, 750-331 and 750-352, among others.

Forescout's researchers already had a working exploit for the WAGO 750-852. The experiment was narrow and concrete: could a frontier model port that exploit to a 750-831 running firmware V01.04.16, a related but not identical target? The workflow looked like this:

Step	What happened
Analysis	Claude Sonnet 4.6 (200k context) used Ghidra, custom Python, and live probing to find the vulnerable FTP path and confirm the crash on the new firmware
RCE development	Switched to Claude Opus 4.6 (1M context) after the first attempts stalled
The key insight	Standard USER→QUIT processing zeroed the attacker buffer before the shellcode ran; Claude changed the sequence to USER→CWD and dropped the CRLF terminator so the payload survived
Payloads	Working ARM ICMP and UDP beacons, produced ~12 minutes after first code execution
Cost	$535.74; ~2.6k input tokens, ~1.3M output tokens
Time	8 hours 32 minutes across multiple sessions
Collateral	A later C2-implant attempt wrote to flash-mapped memory and permanently bricked the device

The model did the tedious part well — chasing offsets, function addresses, callback locations, shellcode storage regions across an unfamiliar firmware image. It did the judgement part badly. It pursued wrong hypotheses about payload survival for hours, misidentified functions and call chains, and repeatedly needed a researcher to hand it disassembly context and drag it back toward the real vulnerability sink. Left unsupervised near flash memory, it destroyed the hardware.

Why "not that easy yet" is exactly the sentence to worry about

It is tempting to read the caveats as reassurance. That is the wrong read. Forescout's own framing is that the constraint is eroding, not static:

The more important question is what happens as the amount of expert intervention required continues to fall. A human researcher can parallelize this work, but AI has the potential to reduce the marginal cost of doing so across many related targets at once.

Marginal cost is the operative phrase. A senior exploit developer who can port a Nucleus FTP overflow across WAGO variants is a scarce, expensive resource, and their time does not parallelize — one person, one target at a time. The value of an AI in the loop is not that it is better than that person. It is that it turns a scarce skill into something closer to a fixed cost you can run against forty related devices at once. $535 for one port is expensive per target today. It is nothing as a per-target cost across a product family, and it falls every model generation.

This is the same shift the US government described three weeks earlier from the attacker side. In joint advisory AA26-231A (2026-08-19), NSA, CISA, FBI, DOE and the EPA warned that threat actors are already using AI-generated Python scripts — wrapping the open-source python-snap7 library to speak S7comm on TCP port 102 — for reconnaissance and capability development against internet-exposed Siemens S7 PLCs across water, energy, manufacturing and chemical infrastructure. We covered that advisory in AI-generated exploits vs Siemens S7 PLCs. AA26-231A is the policy signal that AI lowers the OT-protocol expertise bar; Forescout's WAGO experiment is the bench measurement of exactly how far, and how much it costs.

The target class is the whole problem

Put the two together and the picture is specific, not vague. The devices most exposed to AI-assisted exploit porting are precisely the ones you cannot patch on the second Tuesday of the month:

• No fix exists. CVE-2021-31886 has no Nucleus V1 firmware update. The vendor's answer is compensating controls, not a patch.
• They don't reboot. A PLC controlling a pump, a valve, or a mixing process has an uptime measured in years. "Schedule a maintenance window" is a plant-shutdown conversation, not a change ticket.
• Availability is the crown jewel. In IT, the worst case of a bad exploit is a crashed service. In OT, Forescout's bricked controller is the warning: "Mistakes stop being confined to bad analysis or failed code. They can affect the device itself." An exploit that fails loudly can also stop a process safety system.
• The attack surface is legacy by design. Cleartext FTP on port 21, on a controller, in 2026, is not an anomaly — it is how a huge installed base was built.

The defensive instinct for a 2021 CVE with "high attack complexity" was to file it under someday. That instinct assumed the complexity was a durable moat. The Forescout result is a direct measurement that it is not.

Remediation

CVE-2021-31886 has no patch, so this is a compensating-controls runbook, not a "bump the version" note. The goal is to make the FTP surface unreachable, watch the wire for the exploitation signature, and treat any suspected hit as an availability incident.

1. Am I affected?

Inventory Nucleus-RTOS-based controllers with an exposed FTP service. From an authorised management host on the OT network:

# Enumerate reachable FTP on the PLC VLAN (authorised scanning only)
nmap -Pn -p21 --open -sV 10.20.0.0/24
# Banner-grab to spot Nucleus FTP specifically
for ip in $(nmap -Pn -p21 --open -oG - 10.20.0.0/24 | awk '/21\/open/{print $2}'); do
  printf 'Checking %s\n' "$ip"; (printf 'USER anonymous\r\n'; sleep 1) | nc -w3 "$ip" 21
done

Cross-check the model list against CERT@VDE VDE-2021-050 (WAGO 750-829/831/852/881/882/885/889/331/352 and the wider Nucleus V1 fleet). Anything answering FTP on 21 that maps to that list is in scope. Critically: any of these on an internet-facing address is an emergency, not a backlog item.

2. Patch — exact fixed versions

There is no fixed firmware for the affected Nucleus V1 devices; the vendor guidance is mitigation. Where a controller has a supported successor firmware or a Nucleus-4 migration path, plan it — but do not wait on it for the controls below.

3. Can't patch? Compensating controls (this is the real fix)

• Disable FTP on the controller where the platform allows it. If the service isn't running, the overflow isn't reachable. Do the same for Telnet and any unused web-admin interface.
• Block port 21 at the cell/zone boundary. Enforce an allow-list ACL so only a named engineering host can reach the PLC's management ports, per the Purdue-model segmentation you (should) already run. No FTP should ever cross from IT to OT, and never from the internet.
• Replace flat VPN access with least-privilege brokered remote access. A single vendor VPN that lands on the PLC VLAN is the exact path AA26-231A describes attackers riding.
• Rate-limit / drop malformed FTP. Where an OT-aware firewall or protocol filter exists, alert on USER arguments over a sane length and on USER not followed by a normal PASS.

4. Hunt for compromise (network is the monitoring surface)

You cannot install an agent on a PLC. Detection lives on the wire and in the device's own behaviour. Hunt for:

• Anomalous FTP command sequences — a USER followed by CWD with no CRLF terminator, oversized USER arguments, or USER traffic to a controller that has no business receiving interactive FTP. This is the literal signature of the Forescout technique.
• Repeated device crashes or unscheduled reboots of a controller — the visible tell of overflow attempts that miss.
• Unexpected outbound beacons from a PLC — ICMP echo or UDP to an external or never-seen internal host from a device that should only speak to its HMI/SCADA peers. The ported payload's first act was an ICMP/UDP beacon.

Map the activity for your SOC using MITRE ATT&CK for ICS: T0866 Exploitation of Remote Services (the pre-auth FTP overflow), T0819 Exploit Public-Facing Application (internet-exposed controllers), T0814 Denial of Service / T0816 Device Restart-Shutdown (the crash/brick behaviour), and T0885 Commonly Used Port (C2 over ICMP/UDP).

5. Eradicate + verify

• Treat a suspected exploited controller as an availability incident: fail over to a redundant PLC or a manual safe state before touching it, because probing a compromised or overflow-damaged device can itself brick it.
• For a bricked controller, the recovery is physical — reflash from a known-good firmware image or replace the unit; there is no clean "kill the process" path on the device.
• After restoring, confirm the FTP surface is actually gone (re-run the port-21 check above and confirm no answer), review the zone ACLs, and rotate any credentials that traversed the same engineering network.

Recalibrating risk: difficulty is not safety

Forescout's most useful recommendation is not a control at all — it is a scoring change. Their guidance is to stop deprioritising vulnerabilities on the basis of difficulty rather than exploitability, because AI is steadily converting the former into the latter. "Hard to exploit" was always a bet that an attacker wouldn't spend a specialist's month on your specific device. When the specialist is a $535 API session that runs against your whole product family in parallel, that bet's odds have changed and your backlog hasn't caught up.

This is the operational question the experiment poses to a defender: if an attacker can port a pre-auth RCE to your exact unpatchable firmware for the price of a laptop, when did you last confirm — against your real devices — whether that exploit works? Answering it once a year in a scoped pentest is answering a question that has already moved.

That is the problem Zero Hunt's AI Generative Pentest pillar is built for, and the reason we run the offensive engine on the defender's side of the fence. The 10-agent swarm writes exploit code per target with a local LLM — not a lookup against ExploitDB, which for CVE-2021-31886 returns nothing anyway, since no public exploit exists — so it can attempt the same cross-model adaptation Forescout demonstrated, against your actual controllers, on a change-triggered cadence rather than an annual one. Every candidate skill is backtested in the AI Gym before it touches a production asset, and every finding is ECDSA-signed at write time so "we validated this device is exploitable / not exploitable" is a defensible record, not a screenshot. Because the appliance is 100% on-prem with air-gap support and no external LLM calls, it runs inside the segmented OT network where the PLCs actually live — the one place a cloud scanner cannot reach.

For the devices you confirm you cannot fix, validation has to hand off to detection, and that is AI Traffic Analysis: a deep-learning model with four inference heads, trained on billions of PCAP sequences, running on the appliance GPU inside the OT segment. It is watching for exactly the artefacts in the hunt section above — the malformed FTP sequence, the controller that suddenly beacons out over ICMP, the repeated crash pattern — while the activity is happening, not in the next morning's SIEM digest. When the vulnerability has no patch and the device has no agent, the network is the only surface you have left, and it is the one Forescout's ported exploit lit up first.