Researchers ask Claude to carry an RCE exploit from one PLC to another - AI as an exploit multiplier

Researchers used Claude to port a pre-auth RCE exploit from one industrial automation (PLC) model to another. The exploit porting barrier, which effectively protected less common equipment, has now fallen.

The Facts

The Hacker News reported on September 2, 2026, that a team of researchers documented the use of Claude (Anthropic) to port a pre-auth RCE exploit—remote code execution without authentication—from one industrial programmable logic controller (PLC) model to another in the same segment.

The key insight of the work: the exploit already existed, but it targeted a specific model. Porting it to another model previously required reverse engineering expertise, deep understanding of firmware, and time. The researchers delegated to Claude the adaptation of the code, memory offset mapping, and reconstruction of the exploit chain for the different target.

Who Is Impacted

PLCs are the brains of industrial automation: they control manufacturing lines, water systems, power grids, and traffic lights. The models affected by this type of pre-auth RCE typically include:

• Manufacturing industry (Siemens, Rockwell, Schneider Electric, Omron, Mitsubishi, and their equivalents).
• Critical infrastructure—water, energy, transport—where PLCs are ubiquitous.
• Integrators and engineering firms that deploy these systems for their clients.

We note that the publication is framed by responsible disclosure practices, but it publicly demonstrates what offensive actors are likely already doing internally.

Why This Is Significant

Historically, PLCs were partially protected by their diversity. Each manufacturer, generation, and firmware version had its own quirks. An exploit against a Siemens S7 wouldn’t work against a Rockwell ControlLogix. This fragmentation made porting expensive—thus targeted attacks rare.

What changes with this work:

1. The cognitive cost of porting collapses. What once took weeks for an experienced reverse engineer can now be sketched in a few iterations with an LLM capable of reasoning about firmware.
2. The exploitable surface expands. An exploit published against one “lucky” model (the most studied) quickly becomes a family of exploits against the entire segment.
3. Accountability becomes murky. A researcher who ports an exploit with LLM assistance produces an artifact faster than they can disclose it to affected vendors—the collective vulnerability window opens before patches are available.

This case aligns with the trend we’ve been tracking: agents and LLMs are no longer just assisting humans with defensive code—they amplify offensive capabilities of researchers (and, by extension, attackers) who couldn’t have produced these exploits on their own in a reasonable timeframe.

What to Do Now

• Inventory your PLCs: model, firmware, network exposure. A PLC exposed to the internet in 2026 is a ticking time bomb.
• Segment networks: operational technology (OT) networks must be strictly separated from IT networks. No direct internet access. Use VPN + bastion for remote access.
• Monitor vendor advisories—Siemens ProductCERT, Rockwell PSIRT, Schneider Electric CPCERT. Patch cadence will accelerate.
• Anticipate porting: if a CVE affects a neighboring model in your fleet, consider yourself at risk even without a dedicated exploit.

Key Takeaway: In the PLC ecosystem, security through obscurity (“my model is too rare to be targeted”) no longer holds. What protected equipment was the cost of writing a dedicated exploit; that cost has just been divided by an order of magnitude.