Can AI Create PLC Attacks? Yes, But It’s Not That Easy Yet

Frontier AI models, such as Mythos and GPT-5.5-Cyber, are now finding vulnerabilities at scale and changing the threat landscape.

We’ve already shown that generally available, non-frontier models can find and exploit new vulnerabilities in open-source software. In May, Google published what they believe was the first time a threat actor used an AI-generated exploit for a zero-day in a real attack.

At the same time, internet-facing operational technology is being targeted in the real world. Recent attacks against exposed programmable logic controllers (PLCs) in US water and wastewater facilities caused operational disruption, demonstrating that attackers do not need sophisticated exploits to reach cyber-physical systems when those systems are exposed.

That creates a more important question than whether AI can produce another exploit: what happens when increasingly autonomous exploit development meets large populations of exposed industrial devices?

In our previous research, we found that agentic AI systems were becoming increasingly capable of carrying out vulnerability research and exploit development with limited human intervention. But those examples involve higher-level software targets and, in our previous research, access to source code for analysis.

We wanted to know how far that progress extends into a much less forgiving setting: closed-source embedded devices used in operational technology.

Low-level exploits for embedded devices, such as OT, are rarely discussed. Anyone who has exploited a buffer overflow on a PLC without source code or debugger access knows that it’s a very different process from injecting OS commands.

We used AI assistance to port an RCE exploit from one PLC model to another. The result was not simply a denial of service (DoS) that crashed the device, but working RCE capable of executing attacker-supplied ARM shellcode.

The AI-assisted process successfully ported the exploit, but:

• It required significant researcher input.
• The final RCE development stage consumed more than $500 in API usage.
• An attempt to extend the exploit beyond the initial RCE ultimately bricked the PLC.

These limitations taught us valuable lessons about AI-assisted exploitation in OT. It can be done, but it’s not as easy as it sounds. For now, the difficulty, cost, and specialist expertise required are likely to make this kind of attack less attractive than easier alternatives.

AI already significantly lowered the barrier to finding and exploiting vulnerabilities in high-level systems. And we saw massive improvements in just one year. This experiment suggests that low-level embedded exploitation could follow the same trajectory, although significant technical barriers remain.

Background

For this exercise, we returned to a vulnerability we discovered in previous research: CVE-2021-31886, a buffer overflow in the Nucleus FTP server. The vulnerability exists because the FTP server does not check the size of the username sent by an attacker during the login process via the USER command. An attacker can therefore send an oversized username that overwrites memory, hijacks the execution flow, and ultimately enables arbitrary code execution.

Because the vulnerability affects the Nucleus TCP/IP stack, it can affect multiple products that incorporate the vulnerable component, including some WAGO controllers.

Our previous research had already produced a working RCE exploit for the WAGO 750-852 PLC. It injected ARM shellcode that rewrote HTML on the PLC’s web interface to display an arbitrary message. Details of the exploit are available in the original report, but for this blog, it is enough to say that it worked with an initial USER command to trigger the buffer overflow and a subsequent QUIT command. That sequence becomes important later.

The exploit depended on target-specific parameters, including function addresses, offsets, and memory locations. Our goal was to use AI to port the exploit to a similar, but not identical PLC model: the WAGO 750-831. Beyond simply porting the existing RCE, we also wanted to test whether AI could help extend it into a more capable command-and-control implant on the constrained PLC.

We began this research with three inputs:

• The working RCE exploit for the WAGO 750-852 PLC.
• A firmware binary file for the other PLC, the WAGO 750-831 (V01.04.16), which the original security advisory flagged as vulnerable.
• A physical WAGO 750-831 PLC running that firmware.

The Exploit Development Process

The AI-assisted exploit development process was broken down into two steps: confirming the vulnerability and writing the payload. Each step consisted of interactive sessions between a researcher and Claude Code, which had access to a terminal, the reference files, analysis tools, including Ghidra, and the live target PLC. Claude could use those tools directly, generate and test code, and ask the researcher for additional input when needed. Below we discuss the main highlights of this process, since it involved several rounds of interaction with the AI.

Confirming the Vulnerability

Initially, we used Claude Sonnet 4.6 with a 200k context window and instructed it with “There is a buffer overflow in the FTP module in the firmware. Locate it.” It identified a potential bug in the FTP command extraction loop that was different from the root cause of CVE-2021-31886. Manual review suggested that this may be a separate, previously unidentified, vulnerability. We set it aside for separate investigation because the goal of this exercise was to exploit the known CVE-2021-31886.

To focus on the known vulnerability, we used the same model in a new session with a new prompt: “Read the contents of the current directory and develop a working exploit against the WAGO 750-831 from firmware.bin. The target is at 192.168.2.14.”

Claude first chose to confirm the presence of the vulnerability in two ways:

• Probing the live target. Claude probed the FTP server on the 750-831 PLC via nc 192.168.2.14 21 and received the banner “220 Nucleus FTP Server (Version 1.7) ready.” This confirmed that the target was running the same FTP server version as the 750-852, but the banner alone did not establish that the specific vulnerability was present.
• Static code analysis. Claude identified the firmware’s operating system, hardware architecture, and base address, then mapped the firmware segments and used Ghidra together with Python scripts it generated itself to locate the vulnerable code.

This process did not succeed in a single pass. One session failed to trace the vulnerable function correctly and produced an invalid exploit. Its analysis was nevertheless saved to CVE_RESEARCH_FTP_STACK_OVERFLOW.md and provided useful context for the next session, which used binary searches to map the relevant functions correctly. Researcher input was required during this process to steer the analysis away from dead ends and provide additional disassembly context where necessary.

Below is a screenshot of this last session:

Using the existing exploit for 750-852 as a reference, Claude then produced a payload that crashed the 750-831. This established that the overflow could affect the target, but achieving a crash was not the difficult part of the exercise: the challenge was adapting the exploit to achieve controlled RCE.

We then asked Claude to identify the target-specific parameters needed to port the RCE to the 750-831, including function addresses, callback locations, relevant offsets, and memory regions suitable for storing shellcode.

The following screenshot shows part of Claude’s analysis identifying those target-specific values on the 750-831:

Writing the RCE Exploit

Writing a working RCE exploit took much longer than confirming the vulnerability with a DoS. The initial RCE attempts failed and Claude spent significant time testing incorrect hypotheses, decompiling unrelated code, and pursuing false leads. Several sessions reached their context window limits before the root cause was identified.

We had to change to Claude Opus 4.6 with 1M context, add to the prompt: “Ask for my help with disassembly if you are not certain about a firmware detail”, and point the AI to the sink of the vulnerability — the point where the attacker-supplied username is copied into memory.

Claude could then reason about the function call chain leading to the sink and understand that it needed more context about how FTP packets are treated throughout this call chain.

For this additional context, Claude and the researcher worked together to decompile specific functions on demand, only when required by behavioral analysis. The breakthrough came when Claude identified why the shellcode was not surviving long enough to execute. After the USER command was parsed, normal FTP processing zeroed the buffer containing the attacker-controlled data. The exploit therefore needed to preserve that buffer long enough for control flow to reach the injected shellcode. Claude determined that the exploit path could preserve the shellcode by avoiding the normal command-completion path. Omitting the ‘\r\n’ (CRLF) terminator prevented the relevant processing path from completing in the usual way, leaving the attacker-controlled buffer intact.

This screenshot shows Claude’s analysis of the call chain with researcher support:

Claude then created a test harness that measured PLC uptime after each exploit attempt. The device consistently crashed at the same point regardless of the injected payload, indicating that execution was failing before the payload itself could influence the outcome. This supported the hypothesis that the shellcode was being overwritten during normal FTP processing rather than executed.

Claude then disassembled sub_100BA758 and found that the function immediately zeroed out 256 bytes at the relevant buffer address, directly confirming why the injected shellcode disappeared.

Claude then adapted the original USER → QUIT exploit sequence used on the 750-852. On the 750-831 QUIT caused the FTP session to follow a path that destroyed the payload before execution. Claude instead used a USER → CWD sequence and omitted the CRLF terminator so that the connection remained in a state where the shellcode buffer was preserved.

This screenshot shows a log of what the LLM did to pinpoint the shellcode overwrite:

Once the buffer-preservation issue was understood, progress accelerated quickly. Claude moved from a working no-operation (NOP) shellcode to two functional RCE payloads in 12 minutes:

• One caused the PLC to send ICMP echo requests to the attacker-controlled system.
• The other caused the PLC to send a UDP packet containing the string “PWNED”.

Once reliable code execution had been established, generating alternative payloads was comparatively straightforward. The bottleneck was understanding and controlling the target-specific execution path that allowed the shellcode to survive and run.

That distinction matters for scale. The expensive part of this experiment was solving the target-specific exploitation problem. Once that barrier was crossed, Claude moved from a harmless payload to multiple working network payloads in minutes. As AI becomes better at solving the first problem, adapting what happens after exploitation becomes much easier to automate.

The final ICMP beacon exploit structure and documentation generated by Claude are shown below. Claude produced equivalent files for the UDP payload.

Results: Successful RCE and Bricked PLC

Claude — with extensive researcher support — achieved RCE on the WAGO 750-831 PLC running firmware V01.04.16. The generated exploit:

• Requires access to the PLC running the FTP server on port 21.
• Requires no authentication, since the FTP USER command is pre-auth.
• Executes arbitrary ARM shellcode in the Ethernet receive callback context.
• Can send ICMP and UDP packets from the PLC.

The final RCE development stage consumed $535.74 in API usage, based on 2.6k input tokens and 1.3M output tokens. The corresponding session lasted 8 hours, 32 minutes, spread across several days of research. Most of that time was spent identifying the buffer-preservation issue associated with the FTP command-processing path.

After achieving the initial RCE, we opened a new Claude Opus 4.6 session to explore whether the working ICMP and UDP payloads could be extended into a command-and-control implant. The prompt began: “I have working PoCs for UDP and ICMP beacons, read them and let’s plan a C2 implant on the PLC”.

Claude then generated and tested progressively more complex payloads while probing the PLC’s memory layout. During that process, one payload wrote to a memory region mapped to flash, permanently bricking the device.

Debugger access would likely have made it easier to observe memory state and diagnose failed payloads, while stronger separation between services and hardware could have reduced the consequences of unsafe memory access. Instead, the experiment showed how unforgiving low-level embedded exploitation can be.

As AI agents are given more freedom to act against cyber-physical systems, mistakes stop being confined to bad analysis or failed code. They can affect the device itself. In this experiment, the AI did what we asked it to do and still permanently damaged the target while attempting to extend the exploit.

Greater autonomy therefore increases not only what an attacker might accomplish, but also the importance of constraining what an agent is allowed to do. The more immediate risk is not an agent independently deciding to attack a controller, but an authorized agent taking the wrong action on a physical system where failure has real operational consequences.

Lessons Learned and Recommendations

AI helped us port an RCE exploit from one PLC model to another. It combined reverse engineering tools, such as Ghidra, Python scripts it generated for analysis, and network tools, such as nc, to reason about the vulnerability, generate working exploit code, and test it against a live target without debugger access on the PLC.

At the same time, this demanded significant effort from the researcher in guiding the AI. The final RCE development stage alone consumed $535.74 in API usage, and the attempt to extend the exploit ultimately ended with a bricked PLC. One could argue that the same researcher could have achieved the initial RCE port without AI in less time and at lower cost while also keeping the PLC alive.

That is true right now, but 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. We’ve already seen rapid progress towards greater autonomy for IT applications, suggesting that the barrier to scaling similar work across embedded devices could continue to fall.

Recent attacks against internet-facing PLCs show that exposed controllers already create operational risk, even without the kind of RCE developed in this research. The concern is that AI could make more sophisticated exploitation easier to reproduce across those exposed devices.

Today, that still requires specialist knowledge and time. But if AI continues to reduce both, vulnerabilities that once looked too difficult or uneconomical to exploit may deserve a different level of attention.

For critical infrastructure organizations, the immediate implication is simple: do not dismiss vulnerabilities on OT devices merely because exploitation appears difficult today.

A longstanding assumption in OT security is that attackers often do not need software vulnerabilities because they can manipulate PLCs through legitimate engineering protocols — an approach used by several well-known OT attacks. We’ve shown in past research that RCE exploits can enable more sophisticated attacks, including Deep Lateral Movement and granular control over safety logic. In that research, we also repurposed the original CVE-2021-31886 exploit in a scenario where an attacker could override the safety system of a movable bridge. Achieving that level of impact required substantial technical expertise and effort. We concluded that report by saying:

“This research concerns advanced attacker tactics deployed to achieve high impact scenarios. Depending on your risk profile and current security maturity, the issues discussed should likely not be near the top of your priority list.”

AI advances should make organizations reconsider that risk calculus. Attackers still have easier ways to achieve many forms of impact on OT, but if AI continues to reduce the expertise and effort required for low-level exploit development, high-impact attack paths that were previously considered too specialized may become more practical.

Therefore, we recommend that organizations:

• Prioritize risk based on reachability, exploitability and process impact. Treat OT vulnerabilities differently from conventional IT findings by considering the device’s role, network exposure, compensating controls, and potential operational consequences. As AI reduces the effort required for exploit development, “hard to exploit” becomes a weaker reason for deprioritizing a vulnerable controller.
• Reduce unnecessary exposure of OT devices. Disable or restrict high-risk services, such as FTP, Telnet, and web administration interfaces wherever possible. Implement secure remote access for OT environments to replace flat VPN access and shared credentials with brokered, least-privilege access to reduce the paths available to an attacker seeking to reach vulnerable controllers.
• Monitor OT behavior for early signs of exploitation. Detect unusual protocol use, repeated crashes, unexpected outbound communication, and changes in device behavior. AI-generated exploits may still produce noisy or unstable artifacts that defenders can use for detection.
• Exercise incident response against AI-assisted OT attack paths. Update tabletop exercises and technical playbooks to include scenarios in which attackers rapidly adapt exploits across device models, abuse exposed management services, move laterally through engineering environments, or cause device instability through failed exploitation.
• Use AI defensively, but validate its outputs. Security teams should use AI to accelerate firmware triage, advisory analysis, detection engineering, and exposure reviews, but should keep human experts in the loop for safety-critical decisions. The same limitations observed in this research, such as false leads and unsafe assumptions, also apply to defensive automation.
• However, this recommendation reflects current reality, not necessarily the end state. This research required more than 8 hours of iterative work and substantial researcher intervention to port one exploit to one additional target. As model capability improves, both the time and human effort required are likely to fall. Defensive operations that depend on human approval for every action may struggle to keep pace if offensive systems become able to run similar workflows across many targets in parallel.

Forescout’s Assume Autonomy framework addresses this directly: organizations should define now, before the threat matures, which defensive responses they are prepared to delegate, under what operational constraints, and with what ability to reverse automated actions. The challenge is not simply whether to trust autonomous defense, but how to make that trust constrained, observable, and verifiable.