Los investigadores piden a Claude que lleve un exploit RCE de un PLC a otro: la IA como multiplicador de exploits

Los investigadores han utilizado Claude para transponer un exploit de ejecución de código remota (RCE) pre-autenticación de un modelo de autómata industrial (PLC) a otro. La barrera de la portabilidad de exploits, que de hecho protegía a los equipos menos comunes, acaba de caer.

Los hechos

The Hacker News reporta el 2 de septiembre de 2026 que un equipo de investigadores documentó el uso de Claude (Anthropic) para portar un exploit RCE pre-auth — ejecución de código remoto sin autenticación — desde un modelo de autómata programable industrial (PLC, Programmable Logic Controller) hacia otro modelo del mismo segmento.

El punto clave del trabajo: el exploit ya existía, pero estaba dirigido a un modelo específico. Portarlo a otro modelo requería antes experiencia en reverse engineering, comprensión del firmware y tiempo. Los investigadores delegaron en Claude la adaptación del código, el mapeo de los offsets de memoria y la reconstrucción de la cadena de explotación en el nuevo objetivo.

Quién está afectado

Los PLC son los "cerebros" de los automatismos industriales: controlan cadenas de producción, sistemas de agua, redes eléctricas, semáforos. Los modelos afectados por este tipo de RCE pre-auth suelen ser:

• La industria manufacturera (Siemens, Rockwell, Schneider Electric, Omron, Mitsubishi y sus equivalentes).
• Las infraestructuras críticas —agua, energía, transporte— donde los PLC son omnipresentes.
• Los integradores y estudios de ingeniería que despliegan estos equipos en sus clientes.

Señalamos que la publicación está enmarcada por un trabajo de investigación responsable, pero demuestra públicamente lo que los actores ofensivos probablemente ya practican en privado.

Por qué es significativo

Históricamente, los PLC estaban parcialmente protegidos por su diversidad. Cada fabricante, cada generación, cada firmware tenía sus particularidades. Un exploit contra un Siemens S7 no funcionaba contra un Rockwell ControlLogix. Esta fragmentación hacía que el portaje fuera costoso —por tanto, los ataques dirigidos, raros.

Lo que cambia con este trabajo:

1. El costo cognitivo del portaje se desploma. Lo que antes requería semanas a un experto en reverse engineering ahora puede esbozarse en pocas iteraciones con un LLM capaz de razonar sobre firmware.
2. La superficie explotable se amplía. Un exploit publicado contra un modelo "afortunado" (el más estudiado) se convierte rápidamente en una familia de exploits contra todo el segmento.
3. La cadena de responsabilidad se difumina. Un investigador que porta un exploit con ayuda de un LLM produce un artefacto más rápido de lo que puede divulgarlo a los fabricantes afectados —la ventana de vulnerabilidad colectiva se abre antes de los parches.

Este caso se alinea con la lógica de la línea que seguimos: los agentes y LLM ya no se limitan a asistir al humano en código defensivo, multiplican la capacidad ofensiva de investigadores (y, por extensión, de atacantes) que no podrían producir estos exploits solos en un plazo razonable.

Qué hacer ahora

• Inventariar los PLC: modelo, firmware, exposición en red. Un PLC expuesto en Internet en 2026 es una bomba de tiempo.
• Segmentar: red OT (Operational Technology) estrictamente separada de la red IT, sin acceso directo desde Internet, VPN + bastión para explotación remota.
• Seguir los advisories de los fabricantes —Siemens ProductCERT, Rockwell PSIRT, Schneider Electric CPCERT—. La cadencia de parches se acelerará.
• Anticipar el portaje: si una CVE afecta a un modelo cercano al parque, considere que está en riesgo incluso sin prueba de exploit dedicado.

Para recordar: en el ecosistema PLC, la seguridad por oscuridad («mi modelo es demasiado raro para ser atacado») ya no se sostiene. Lo que protegía un equipo era el costo de escribir un exploit dedicado; ese costo acaba de dividirse por un orden de magnitud.