Des chercheurs demandent à Claude de porter un exploit RCE d'un PLC à un autre - l'IA comme démultiplicateur d'exploits

Des chercheurs ont utilisé Claude pour transposer un exploit RCE pre-auth d'un modèle d'automate industriel (PLC) à un autre. La barrière du portage d'exploit, qui protégeait de fait les équipements moins courants, vient de tomber.

Les faits

The Hacker News rapporte le 2 septembre 2026 qu'une équipe de chercheurs a documenté l'usage de Claude (Anthropic) pour porter un exploit RCE pre-auth - exécution de code à distance sans authentification - depuis un modèle d'automate programmable industriel (PLC, Programmable Logic Controller) vers un autre modèle du même segment.

Le point clé du travail : l'exploit existait déjà, mais il ciblait un modèle précis. Le portage vers un autre modèle demandait auparavant une expertise reverse engineering, une compréhension du firmware et du temps. Les chercheurs ont délégué à Claude l'adaptation du code, le mapping des offsets mémoire, la reconstruction de la chaîne d'exploitation sur la cible différente.

Qui est impacté

Les PLC sont des cerveaux d'automates industriels : ils pilotent les chaînes de production, les systèmes d'eau, les réseaux électriques, les feux tricolores. Les modèles concernés par ce type de RCE pre-auth touchent typiquement :

• L'industrie manufacturière (Siemens, Rockwell, Schneider Electric, Omron, Mitsubishi et leurs équivalents).
• Les infrastructures critiques - eau, énergie, transport - où les PLC sont légion.
• Les intégrateurs et bureaux d'études qui déploient ces équipements chez leurs clients.

Nous notons que la publication est encadrée par un travail de recherche responsable, mais elle démontre publiquement ce que les acteurs offensifs pratiquent probablement déjà en interne.

Pourquoi c'est significatif

Historiquement, les PLC étaient partiellement protégés par leur diversité. Chaque constructeur, chaque génération, chaque firmware avait ses spécificités. Un exploit contre un Siemens S7 ne fonctionnait pas contre un Rockwell ControlLogix. Cette fragmentation rendait le portage coûteux - donc les attaques ciblées, donc rares.

Ce qui bascule avec ce travail :

1. Le coût cognitif du portage s'effondre. Ce qui prenait des semaines à un reverseur expérimenté peut désormais être esquissé en quelques itérations avec un LLM capable de raisonner sur du firmware.
2. La surface exploitable s'élargit. Un exploit publié contre un modèle « chanceux » (le plus étudié) devient rapidement une famille d'exploits contre tout le segment.
3. La chaîne de responsabilité se brouille. Un chercheur qui porte un exploit avec l'aide d'un LLM produit un artefact plus vite qu'il ne peut le divulguer aux constructeurs impactés - la fenêtre de vulnérabilité collective s'ouvre avant les patches.

Ce cas rejoint la logique du fil que nous suivons : les agents et LLM ne se contentent plus d'assister l'humain dans du code défensif, ils démultiplient la capacité offensive de chercheurs (et par ricochet, d'attaquants) qui n'auraient pas pu produire ces exploits seuls dans un délai raisonnable.

À faire maintenant

• Inventoriez vos PLC : modèle, firmware, exposition réseau. Un PLC exposé sur Internet, en 2026, est une bombe à retardement.
• Segmentez : réseau OT (Operational Technology) strictement séparé du réseau IT, pas d'accès direct depuis Internet, VPN + bastion pour l'exploitation à distance.
• Suivez les advisories des constructeurs - Siemens ProductCERT, Rockwell PSIRT, Schneider Electric CPCERT. La cadence des patchs va s'accélérer.
• Anticipez le portage : si une CVE touche un modèle voisin de votre parc, considérez-vous à risque même sans preuve d'exploit dédié.

À retenir : dans l'écosystème PLC, la sécurité par l'obscurité (« mon modèle est trop rare pour être ciblé ») ne tient plus. Ce qui protégeait un équipement, c'était le coût d'écrire un exploit dédié ; ce coût vient d'être divisé par un ordre de grandeur.