AI Just Helped Turn One PLC Exploit Into Another — and It Took Less Than $600
- The Mess: Forescout researchers used Claude to adapt a working remote-code-execution exploit from one WAGO PLC model to another, eventually producing working payloads after more than eight hours of AI-assisted reverse engineering.
- The Damage: AI-assisted exploit development could lower the expertise and time required to attack industrial controllers used in water, energy and manufacturing environments.
- The Fix: Keep PLCs off the public Internet, patch known vulnerabilities, segment OT networks and assume that AI will increasingly reduce the effort required to adapt existing exploits.
The scary part isn’t that AI found a new vulnerability.
It didn’t.
The scary part is that it helped turn an old exploit into a working attack against another industrial controller.
Researchers from Forescout’s Vedere Labs tested whether an AI model could adapt an existing remote-code-execution exploit from one WAGO programmable logic controller to another.
The answer was:
Yes.
But not autonomously.
And that distinction matters.
The Starting Point Was an Old WAGO Exploit
The researchers already had a working exploit for the WAGO 750-852 PLC.
It targeted CVE-2021-31886, a pre-authentication buffer overflow in the Nucleus FTP server.
The vulnerability can allow an unauthenticated attacker to execute ARM shellcode on an affected PLC.
The experiment attempted to move that exploit to a different WAGO model:
WAGO 750-831.
The goal was simple.
Take something that already works.
Make it work somewhere else.
That’s exactly the kind of task AI could eventually make dramatically cheaper.
Claude Got the PLC to Crash
The researchers gave Claude Code access to a serious toolkit.
The environment included:
- a terminal
- firmware reference files
- Ghidra
- the physical PLC
- networking tools
- the target firmware
Claude first analyzed the firmware and interacted with the actual device.
Eventually it produced a payload capable of crashing the PLC.
That confirmed something important:
the vulnerability existed on the second model too.
But a crash isn’t RCE.
Getting the device to execute controlled attacker code was considerably harder.
Then the AI Hit a Wall
The first attempt used Claude Sonnet 4.6.
It repeatedly went down incorrect paths.
The researchers had to redirect the model.
They had to provide additional technical context.
They had to explain what was happening on the hardware.
And they had to help it avoid false leads.
Eventually the team switched to Claude Opus 4.6.
That’s where things accelerated.
The Shellcode Kept Disappearing
The key technical problem was surprisingly simple.
The injected code wasn’t surviving long enough to execute.
Claude eventually figured out why.
It changed the exploitation strategy so the payload would remain intact.
Then the process accelerated dramatically.
Once that obstacle was solved, the model produced two working RCE payloads in approximately 12 minutes.
That’s the interesting number.
Not eight hours.
Not the total research time.
Twelve minutes after the hard part was solved.
The Entire Process Still Took More Than Eight Hours
This is where headlines can become misleading.
The experiment did not demonstrate an autonomous AI hacker that receives a PLC and instantly produces a working exploit.
Researchers had to supervise the model extensively.
The complete RCE development process took approximately 8 hours and 32 minutes and consumed around $535.74 in API usage.
Human expertise remained essential.
The researchers had to recognize when the model was heading in the wrong direction.
They had to understand the firmware.
They had to interpret crashes.
They had to decide what information to provide.
The AI was an accelerator.
It wasn’t the entire exploit team.
Then Things Went Wrong
The researchers attempted to take the experiment further.
The next objective was to create a command-and-control implant.
Claude started experimenting with increasingly complex payloads.
One attempt wrote into a memory region mapped to the PLC’s flash.
The result:
the PLC was permanently bricked.
That’s almost a perfect demonstration of both sides of AI-assisted exploitation.
The model can move extremely quickly once it understands the problem.
It can also make a catastrophic mistake extremely quickly.
This Is Not a New Zero-Day
The underlying vulnerability is CVE-2021-31886.
It isn’t a newly discovered flaw.
The original exploit already existed.
What changed was the cost of adapting it.
That’s important.
Attackers don’t need a new zero-day for every device.
They can take an existing exploit and attempt to port it to related hardware.
Historically, that required a specialist who understood:
- embedded systems
- ARM architecture
- firmware
- memory corruption
- debugging
- exploit development
AI can increasingly assist with those tasks.
PLCs Are Different From Normal Servers
A compromised web server is bad.
A compromised PLC can affect physical processes.
PLCs control industrial equipment.
They can interact with:
- pumps
- valves
- motors
- sensors
- production machinery
- HVAC
- industrial control systems
An attacker who obtains code execution isn’t necessarily interested in stealing files.
They may want to change what the machine does.
Water Infrastructure Makes This More Interesting
The research arrives at a particularly uncomfortable moment.
Recent attacks have targeted water and wastewater utilities in the United States.
Attackers have demonstrated that industrial controllers can become operational targets rather than merely IT assets.
The White House has also launched Project Watershed 250, aimed at helping water utilities strengthen their cybersecurity.
That gives the research a very practical context.
The question isn’t whether AI can attack some obscure laboratory device.
It’s whether the same techniques eventually make attacks against real OT environments easier.
The Barrier Is Coming Down
Industrial exploit development has traditionally been expensive.
You need:
hardware
plus:
firmware
plus:
reverse engineering
plus:
specialist knowledge
plus:
time
AI doesn’t eliminate all of those requirements.
But it can reduce the amount of human effort required for each step.
That changes the economics.
An attacker who previously needed an expensive specialist may eventually need only someone capable of directing an AI system and understanding its output.
The Most Important Part Happens After RCE
The Forescout experiment showed that AI could help achieve code execution.
That’s only the beginning.
Once an attacker has RCE, they may want to:
- maintain persistence
- communicate with command-and-control infrastructure
- move laterally
- manipulate industrial processes
- disable monitoring
- alter configurations
- disrupt operations
The researchers attempted to automate this next stage.
That’s where the experiment became unstable and eventually bricked the PLC.
But the direction is obvious.
The difficult part today may become the easy part tomorrow.
Defenders Get AI Too
There is an obvious counterargument.
If attackers can use AI, defenders can too.
Absolutely.
AI can help security teams:
- analyze firmware
- identify suspicious behavior
- generate detection rules
- reverse engineer malware
- search vulnerability patterns
- monitor OT networks
The problem is asymmetry.
An attacker only needs one successful path.
The defender needs to protect the entire environment.
Patch the Old Bugs
The simplest defense hasn’t changed.
CVE-2021-31886 is years old.
Organizations operating affected devices should patch them where possible.
If patching isn’t possible:
- isolate the PLC
- block unnecessary protocols
- restrict management interfaces
- segment OT from IT
- monitor unusual network traffic
- disable unnecessary services
- restrict remote access
Most importantly:
don’t expose industrial control systems directly to the Internet.
Don’t Confuse Research With Active Exploitation
There is another important distinction.
Forescout’s work was conducted in a controlled research environment.
This isn’t evidence that criminals are currently using Claude to compromise WAGO PLCs at scale.
The research demonstrates feasibility.
It shows what AI-assisted exploit development can accomplish today with expert supervision.
That’s already significant.
We don’t need to exaggerate it into an autonomous cyberweapon.
The $535 Number Is the Real Warning
Five hundred dollars isn’t much for a sophisticated exploit-development project.
It’s especially cheap compared with the cost of hiring a specialist.
Today, the experiment required experts and more than eight hours.
Tomorrow, the same process may require significantly less.
That’s the trajectory defenders should care about.
Not:
“Can AI hack a PLC?”
It already helped.
The real question is:
How much cheaper will the next one be?
Bugstoday Opinion
This is the kind of AI security story that deserves more attention than another chatbot jailbreak.
The researchers didn’t ask Claude to write a toy exploit.
They gave it a real PLC, firmware, reverse-engineering tools and an existing RCE.
After enough human guidance, it adapted the attack to another industrial device and produced working payloads.
Today it took eight hours and $535.
Tomorrow?
Maybe considerably less.
Bugstoday verdict: AI doesn’t need to become an autonomous hacker to change industrial security. If it can reduce a specialist’s eight-hour exploit-porting job to a much shorter supervised workflow, the economics of attacking PLCs have already started changing. OT defenders should assume that existing exploits will become increasingly portable — and that “the attacker probably doesn’t have the expertise” is becoming a much weaker security assumption.
Today’s Bugs. Tomorrow’s Breaches.
Sources
- Forescout Vedere Labs — R4IoT / PLC Security Research
- SecurityWeek — AI-Assisted WAGO PLC Exploit Research
- Cybersecurity Dive — Frontier AI and PLC Exploitation
- NVD — CVE-2021-31886
- WAGO — Security Advisories
