Forescout Ported a WAGO PLC Exploit With Claude Code for $535.74 — and Bricked the Controller Trying for More

On 1 September 2026, Forescout Research's Vedere Labs published an experiment in which it gave Claude Code a terminal, the reverse-engineering tool Ghidra, a firmware binary and a physical WAGO 750-831 controller, then asked it to port a pre-authentication remote code execution exploit that already worked on the closely related WAGO 750-852. The model got there: it worked out why its shellcode kept being erased, changed the trigger sequence, and executed attacker-supplied ARM shellcode on live hardware with no credentials. The cost was 8 hours 32 minutes of session time spread over several days, $535.74 in API usage and continuous human steering. A later attempt to extend the exploit into a command-and-control implant wrote to a flash-mapped memory region and permanently bricked the controller — the researchers' own test unit, not equipment in the field. The experiment is one record in the AI incident archive, which holds the full record set, its sources and the neighbouring entries in this series.

What Forescout actually handed the model

The setup matters more than the headline number, because it decides what the experiment does and does not show. Vedere Labs' own account describes an interactive arrangement: Claude Code had a terminal, the reference files, analysis tooling including Ghidra, and network access to a live target at 192.168.2.14 — a WAGO 750-831 running firmware V01.04.16. Researchers could intervene at any point during the session. There was no debugger and no source code for the target firmware, according to the Cloud Security Alliance's research note on the case.

The flaw was already known and already documented. CVE-2021-31886 is a stack-based buffer overflow in the Nucleus FTP server, reachable before authentication on TCP port 21 by sending an oversized USER command, and Forescout's earlier work had already produced a working exploit for the 750-852. The Hacker News reports the CVSS score as 9.8, assigned by Siemens, which maintains Nucleus. The original advisory is CERT@VDE's VDE-2021-050.

So this was not autonomous vulnerability discovery. It was a supervised port: one known bug, one working reference exploit, one sibling device, an expert on hand. Forescout's language is precise about that, and its own conclusion is that the barrier remains high. What the experiment measures is the marginal cost of moving an exploit from a device someone has already broken to the next device in the same family — which, as the Cloud Security Alliance note puts it, is the step that decides whether a patch gap on one model is a patch gap on all of them.

Eight hours, and a 256-byte buffer

The first thing worth recording is how much of the session was spent being wrong. Forescout says the model's very first prompt surfaced a different potential FTP bug, not CVE-2021-31886; researchers set it aside, and the company says manual review suggests it may be a separate, previously unidentified vulnerability with no CVE assigned. One later session failed to trace the vulnerable function correctly and produced an invalid exploit. The model pursued false hypotheses, decompiled unrelated code, and ran out of context.

It did get one intermediate result: a payload that crashed the 750-831, which proved the overflow reached the second device without yet giving controlled execution. That distinction — crash versus control — is where the session stalled. Every payload the model built was being erased before it could run, and the reason turned out to be ordinary FTP handling on the target: after the oversized USER command, normal processing zeroed a 256-byte buffer that held the attacker's shellcode. Forescout says finding the culprit required human-directed analysis of the call chain and the sink, and identifies the routine as sub_100BA758.

The fix was a sequence change. The 750-852 exploit sent USER followed by QUIT. On the 750-831 the model switched to USER followed by CWD, and omitted the CRLF terminator on the command, so the processing path never completed in the usual way and the buffer survived long enough to execute. The exploit then ran in the Ethernet receive callback context. According to Forescout, the capability demonstrated stops at sending network packets.

Once code execution was reliable, the pace changed completely. The model went from no-op shellcode to two working network payloads in 12 minutes: one sending ICMP echo requests to an attacker-controlled host, the other a UDP packet containing the string "PWNED". That 12-minute figure is the most consequential number in the whole record, and it is the one Forescout's write-up treats as the warning — the hard part was the first step, and the steps after it were nearly free.

The bill: $535.74 for a port a human might have done faster

For the final remote-code-execution stage, Forescout reports $535.74 in API usage across a session of 8 hours and 32 minutes, with the work spread over several days of research rather than run in one sitting. The token figures it publishes are 2.6k input and 1.3M output.

That split is unusual enough to flag. In a long agentic coding session the input side normally dominates, because the model is re-sent a growing context on every turn; an 8.5-hour session billed at 2,600 input tokens is not a complete accounting of what the context cost. Forescout publishes no breakdown, and SecurityWeek, reporting the same stage on the same day, gives only "more than $500" and no token figures at all. The dollar total is the number both accounts support; the input/output split should be read as reported, not as a full billing record.

Cost is the weakest part of the case for AI assistance, and Forescout says so itself. The company's own assessment is that a researcher could have ported this exploit "without AI in less time and at lower cost while also keeping the PLC alive." The experiment is not an argument that the model is cheaper than an expert. It is an argument about which way that comparison is moving.

The bricked controller

The failure is the part of this record with a physical result. After code execution was established, a follow-up session tried to extend the exploit into a command-and-control implant. Forescout says the payloads grew progressively more complex, and one of them wrote to a memory region mapped to flash. The controller was permanently bricked.

Three things are worth separating here. The device was the researchers' own test hardware, so no operator lost a production line and the archive records no real harm. The damage was done by an agent with legitimate access to the equipment, doing a task its operators had asked for — not by an attacker. And the write was irreversible in a way that a bad line of code on a server usually is not: flash on an embedded controller is not a file you can revert. Forescout's framing follows directly from that. The immediate risk it names is not an agent deciding on its own to attack a controller, but "an authorized agent taking the wrong action on a physical system" where failure has operational consequences.

What is established, and what is not

The archive grades this record confidence A, severity medium, not disputed, with no real harm recorded — and the reporting behind it holds up on those terms. Forescout's write-up is the primary account. SecurityWeek published its own report on 1 September 2026, the same day; The Hacker News and the Cloud Security Alliance's research lab both published on 2 September. None of those is an independent technical replication, and none claims to be, but they agree on the mechanism, the two model versions, the cost, the 12-minute payload run and the bricking.

Established, on that record:

• That a supervised port succeeded. A pre-authentication exploit for CVE-2021-31886 was adapted from the WAGO 750-852 to a 750-831 on firmware V01.04.16, and ARM shellcode supplied by the operator executed on the live device.

• The mechanism. The 256-byte buffer being zeroed by normal USER handling, the switch from QUIT to CWD, and the omitted CRLF terminator are described consistently by Forescout and by the secondary coverage.

• The figures for the final stage: 8 hours 32 minutes, $535.74, 2.6k input and 1.3M output tokens, 12 minutes from code execution to two working payloads.

• That the C2 extension bricked a controller, and that it was a test unit.

• That Forescout's own verdict is negative on cost. It states plainly that a human researcher could likely have done this port faster and more cheaply, and without destroying the hardware.

Not established, or in tension:

• Independent technical validation. Every published account, including the Cloud Security Alliance's analysis, traces back to Forescout's description of its own work. Nobody outside Forescout has reproduced the port, and SecurityWeek's report carries no independent expert comment.

• The calendar dates of the sessions. Forescout gives durations, not dates. The only firm date in the record is the publication date, 1 September 2026.

• How many WAGO models the underlying advisory covers. The Hacker News reproduces an affected list of ten models from CERT@VDE's VDE-2021-050; the Cloud Security Alliance note puts the figure at 19. The advisory itself is the authority, and the discrepancy is a reason to check it rather than to quote either number.

• The exact input-token accounting, as described above.

• What the failed implant actually did. Forescout says a payload wrote to a flash-mapped region; it does not publish the payload, the address or the sequence, so the bricking cannot be reconstructed from the outside.

WAGO's side: no update available

The reason a port to a sibling model matters is that the sibling is not going to be fixed. CERT@VDE's VDE-2021-050 lists 750-series controllers running the Nucleus V1 real-time operating system as affected, and states: "At the moment, there are no updates for this version available." The Hacker News notes that two models on the affected list, the 750-882 and the 750-885/0xx-xxx, are absent from both the advisory's mitigation section and its remediation table, leaving their status unclear.

Siemens, which maintains Nucleus, says no remediation is planned for Nucleus NET across all versions, according to The Hacker News, while Nucleus ReadyStart V3 releases from V2013.08.1 onward already fix CVE-2021-31886. That is small comfort for a controller whose firmware ships the older stack and whose vendor has published no update path.

The flaw is not new. CVE-2021-31886 was one of 13 vulnerabilities disclosed in November 2021 under the name NUCLEUS:13 by Forescout and Medigate. The Hacker News also checked, on 1 September 2026, whether public exploit code for it was easy to find: a GitHub repository search returned nothing, and the flaw was absent from Exploit-DB and Packet Storm — with the caveat that GitHub's search covers repository names and descriptions rather than file contents. A port that took Forescout eight and a half hours and more than five hundred dollars did not come from a copy-paste.

Why Forescout says the trend line matters anyway

Forescout's conclusion is deliberately unexciting, and it is the part of the record most likely to be misread in either direction. "It can be done, but it's not as easy as it sounds," the company writes. It notes that its own earlier NUCLEUS:13 research concluded these issues probably should not sit near the top of an asset owner's priority list, and says advances in AI should prompt organisations to revisit that assessment — because "hard to exploit" becomes a weaker reason to deprioritise a controller as the effort required to exploit it falls.

The Cloud Security Alliance's note supplies the useful shorthand for the pattern: hard first step, fast subsequent steps. The first adaptation cost eight and a half hours, expert supervision and a destroyed device. The second and third payloads took twelve minutes. If the first step gets cheaper, the ratio does not stay where it is.

That argument lands against a specific backdrop, though it is separate from the Forescout experiment and should not be read as evidence about it. The Hacker News reports that on 19 August 2026 the NSA, CISA, the FBI, the Department of Energy and the EPA issued a joint advisory warning about AI-generated exploitation scripts aimed at internet-exposed Siemens S7 PLCs; the agencies assessed the activity was likely intended for persistent reconnaissance and capability development, and did not attribute it. The same outlet reports FBI and EPA findings of intrusions at water utilities in at least seven states since 27 July 2026, some of which degraded operations, in which attackers changed IP addresses and passwords on internet-facing Rockwell Automation MicroLogix controllers without needing an exploit at all. The joint advisory warned that AI for exploit generation was "dramatically reducing the technical expertise and time required" to build working ICS attack tools.

What an operator should take from it

The practical response is the unglamorous one, and it does not depend on how the AI argument resolves. Identify whether any 750-series or other Nucleus-based controller is on the network and what firmware it runs. Where no update exists, restrict or disable FTP, Telnet and web administration, block port 21 at the boundary, segment the control network, and do not expose management interfaces to the internet. Monitor for unusual protocol use, repeated crashes and unexpected outbound traffic — a crash on a controller is a signal, not just an outage.

The Cloud Security Alliance adds a step that follows from the experiment's own logic: independently verify whether sibling models share a vulnerability rather than assuming a vendor's patch scope matches actual exposure. That is the check Forescout ran on one pair of devices, and its argument is that the same check gets cheaper as the first step does.

For teams using agents near physical systems, the bricking is the concrete lesson. Forescout's recommendation is to keep human experts in the loop for safety-critical decisions and to make trust in autonomous defence "constrained, observable, and verifiable" — approval gates before writes to firmware or flash, rollback where it exists, and testing on non-production hardware, because on an embedded controller a wrong write does not roll back.

The record will read differently depending on what you expected from it. It is not a demonstration that a model can be pointed at an industrial controller and left alone; the same company that ran it says a person could have done the job faster and more cheaply. What it does show is a measured price for the step that used to require a specialist: eight and a half hours, five hundred and thirty-five dollars, sustained expert supervision, and one dead controller.