AI can help build a working exploit for a programmable logic controller. That statement is true, but it leaves out nearly everything security leaders need to know.
In research published on September 1, 2026, Forescout’s Vedere Labs used AI to port a remote code execution exploit from one WAGO PLC model to another. The target was a closed-source embedded system. The researchers did not have source code or debugger access on the PLC, and the vulnerability required low-level analysis of firmware and memory behavior.
The effort succeeded. It also required extensive human guidance, consumed $535.74 in API usage during the final RCE stage, lasted 8 hours and 32 minutes, followed false leads and ultimately bricked the PLC while attempting to add command-and-control capability.
The Vedere Labs technical analysis shows where AI helped, where expertise remained essential and why cyber-physical systems require a different standard for autonomous action.
What did the researchers test?
The team worked with CVE-2021-31886, a pre-authentication buffer overflow in the Nucleus FTP server. A vulnerable FTP service could receive an oversized username through the USER command, allowing an attacker to overwrite memory and redirect execution.
The researchers asked AI to adapt a working WAGO 750-852 exploit to a WAGO 750-831 running firmware version V01.04.16.
This distinction matters. The experiment did not ask AI to discover an unknown weakness and independently attack an arbitrary industrial environment. It asked the system to port a known exploit between related devices with a researcher supervising the process and supplying target-specific context.
The final exploit required no authentication, executed arbitrary ARM shellcode and produced working ICMP and UDP payloads.
Where AI accelerated the work
The difficult phase was understanding why the exploit crashed the target without producing controlled code execution. The AI pursued incorrect hypotheses and needed the researcher to redirect it, provide additional disassembly context and identify the relevant vulnerability sink. Several sessions reached their context limits.
The breakthrough came from recognizing that normal FTP processing erased the buffer containing the injected shellcode. The exploit path had to preserve that data long enough for execution to reach it. Once reliable code execution existed, the pace changed sharply.
According to Vedere Labs, the AI moved from a working no-operation payload to two functional network payloads in 12 minutes. One made the PLC send ICMP echo requests. The other sent a UDP packet containing a short test string.
The evidence suggests that initial, target-specific exploit development remains the bottleneck. After that barrier falls, adapting post-exploitation behavior can become much cheaper and faster.
Where the AI still depended on experts
The headline result should not obscure the amount of scaffolding around it.
The researcher provided the known vulnerability, an exploit for a related PLC, the firmware, a live target, specialist tools and repeated guidance. The final RCE stage used 1.3 million output tokens and 2,600 input tokens, cost $535.74 and took 8 hours and 32 minutes.
The researchers acknowledge that an expert might have completed the port faster and more cheaply without AI. This gives defenders a grounded baseline rather than a speculative forecast.
The experiment also revealed a more immediate risk. While testing a more capable implant, an AI-generated payload wrote to flash-mapped memory and permanently bricked the PLC. The system did what it was asked to do, but its action damaged the device.
What does AI-assisted exploitation change for OT risk?
The research does not prove that attackers can autonomously compromise PLC fleets. It shows a plausible path toward cheaper exploit adaptation across related models.
For defenders, “hard to exploit” should therefore be treated as a time-sensitive assumption rather than a permanent property. The priority of an OT vulnerability should depend on several factors:
● The exact device model and firmware version.
● The vulnerable service and whether it is enabled.
● Network reachability from likely attacker positions.
● Authentication requirements.
● Available compensating controls.
● The industrial process and safety function connected to the device.
● The consequences of exploitation and failed remediation.
This is why generic vulnerability severity is particularly weak in OT. Two PLCs with the same CVE can present radically different operational risk when one is isolated and the other is reachable from a compromised engineering workstation.
Why OT remediation needs stronger guardrails
AI-assisted defensive automation faces similar hazards. A wrong action on a controller can interrupt production, corrupt a device or affect a physical process.
Our interpretation for remediation platforms is straightforward: the more physical the consequence, the narrower the automation boundary should be.
Safe OT remediation should include:
1. Identify the exact device and firmware before recommending an action.
2. State what evidence supports the recommendation.
3. Test against a representative device or simulation where possible.
4. Require human approval for changes affecting availability or safety.
5. Limit credentials, network access and asset scope.
6. Prepare recovery for devices without reliable rollback.
7. Validate that exposure changed without disrupting the process.
These safeguards are our product implications, not findings tested by the researchers.
How this relates to remediation
The remediation position should focus on options and evidence. Vicarius for manufacturing and OT addresses environments where operational continuity shapes security decisions. Its remediation model includes patching, scripted actions and patchless protection.
The research strengthens the case for patchless protection as a temporary option in supported scenarios. It does not prove that any specific protection blocks CVE-2021-31886 or secures PLC firmware.
OT teams need to reduce exposure while respecting change windows, device constraints and process safety. AI can help with analysis, but action must remain bounded and validated.
Frequently asked questions
Did AI independently create the PLC exploit?
No. AI helped port an existing exploit between related WAGO models. Researchers supplied the known CVE, reference exploit, target firmware, tools, physical device and significant expert guidance.
How long did the AI-assisted exploit take?
The final RCE development stage lasted 8 hours and 32 minutes across several days and consumed $535.74 in API usage. Once code execution worked, two additional network payloads were produced within 12 minutes.
Why does the bricked PLC matter to defenders?
It shows that authorized AI agents can cause physical damage through an incorrect action. Defensive AI operating on OT assets therefore needs stricter permissions, testing and human oversight than automation on ordinary endpoints.
The practical takeaway
AI-assisted PLC exploitation is real, but it is not effortless or autonomous in this study. Specialist knowledge, target context and human correction remained central.
Once an exploit path is understood, AI may reduce the effort needed to adapt payloads across related targets. OT defenders should prepare without pretending the technology has reached full autonomy.
That means finding exposed devices, understanding their operational role, reducing unnecessary reachability and choosing remediation actions that are safe enough for the physical systems they protect.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
.webp)
