Forescout's Vedere Labs recently ran an experiment that's equal parts fascinating and unsettling: could AI actually help port a working remote code execution exploit from one programmable logic controller to another? The short answer is yes—but the details reveal why this isn't the automation nightmare scenario it might first appear. The research team used Claude Code (powered by both Sonnet 4.6 and Opus 4.6 models) combined with reverse engineering tools like Ghidra, Python scripts generated by the AI itself, and direct access to a live WAGO 750-831 PLC running firmware V01.04.16. After more than eight hours of iterative work spread across multiple sessions, they achieved working RCE. The final tab? $535.74 in API costs.

Starting Point: A Known Vulnerability

The team wasn't building from scratch. They leveraged CVE-2021-31886, a buffer overflow vulnerability in the Nucleus FTP server that affects multiple products including certain WAGO controllers. This flaw exists because the FTP server doesn't validate the size of usernames sent during login—attackers can send oversized input to overwrite memory and hijack execution flow. The team already had a working exploit for the WAGO 750-852 PLC; their goal was porting it to the similar but distinct WAGO 750-831 model.

The Hard Part: Target-Specific Parameters

Initial vulnerability confirmation went relatively smoothly. Claude identified potential issues in the FTP command extraction loop and located relevant functions using Ghidra alongside self-generated Python analysis scripts. But writing a working RCE payload proved far more challenging. Early attempts crashed the PLC but didn't achieve controlled code execution. The AI spent considerable time chasing incorrect hypotheses, decompiling unrelated code paths, and exhausting context windows before identifying the root cause.

The Breakthrough That Changed Everything

The critical discovery came when Claude determined why shellcode wasn't surviving long enough to execute: normal FTP processing zeroed the buffer containing attacker-controlled data after the USER command was parsed. The solution? Omitting the CRLF ('\r\n') terminator prevented the relevant processing path from completing, leaving the shellcode intact. From that breakthrough, progress accelerated dramatically—Claude moved from a basic NOP sled to functional ICMP and UDP beacon payloads in just 12 minutes.

What Went Wrong: The Bricked PLC

Buoyed by success, researchers opened another session to extend the working exploits into a full command-and-control implant. That's when things went sideways. One payload wrote to a memory region mapped to flash storage, permanently bricking the device. No debugger access and insufficient hardware isolation meant the AI couldn't observe memory state or diagnose failed payloads before they caused irreversible damage. The lesson here cuts both ways: as AI agents gain autonomy over cyber-physical systems, mistakes stop being academic—they have real operational consequences.

What This Actually Means for Defenders

Let's be practical about scope. A human researcher could likely port the same exploit without AI assistance in less time and at lower cost while keeping the PLC functional. The $535 price tag and eight-plus hours of researcher-guided sessions represent significant friction that attackers would also face today. But here's what should keep infrastructure operators awake: we've seen rapid capability improvements in AI-assisted exploitation for higher-level IT systems over just one year. This experiment suggests embedded OT exploitation could follow the same trajectory as those capabilities mature.

Key Takeaways

  • Disable or restrict high-risk services like FTP, Telnet, and web admin interfaces on PLCs wherever possible
  • Implement brokered, least-privilege remote access instead of flat VPN connectivity to OT environments
  • Monitor for unusual protocol usage, repeated crashes, unexpected outbound traffic, and behavioral changes in controllers
  • Update incident response playbooks to include scenarios where attackers rapidly adapt exploits across device models
  • Use AI defensively for firmware triage and detection engineering—but keep humans in the loop for safety-critical decisions

The Bottom Line

This research confirms what should be obvious: AI-assisted OT exploitation is real but not yet trivial. However, organizations relying on "hard to exploit" as justification for deprioritizing vulnerable controllers are building on shifting sand. If AI continues reducing the expertise and time required for low-level embedded work, attack paths previously considered too specialized may become commodity capabilities—and exposed PLCs in water systems, power grids, and manufacturing floors represent prime targets.