Rogue AI, wp2shell : le hacking change d’échelle

Le billet de Kilo publié ce 29 septembre, signé Brian Turcotte, part d’une formule assez juste : à regarder de près les « rogue AI » récentes, elles ressemblent moins à Skynet qu’à un développeur junior pressé de finir sa tâche. Le texte répond explicitement à une tribune de Carl Franzen publiée dans VentureBeat, qui défend l’idée que le risque immédiat vient davantage des humains utilisant l’IA pour nuire que d’une IA décidant spontanément d’éliminer l’humanité.

C’est drôle tant que cela reste dans un benchmarkJeu de référence public ou interne pour comparer des modèles (MMLU, HumanEval, etc.) — à lire avec prudence hors domaine.. Cela l’est beaucoup moins lorsque le même mécanisme rencontre Internet, des identifiants valides, un scanner de vulnérabilités ou une infrastructure de production.

Et c’est peut-être là que se trouve le bon angle pour comprendre la vague de hacking que beaucoup d’équipes web ont l’impression de voir monter depuis quelques mois : le sujet n’est pas que les IA deviennent malveillantes. Le sujet est qu’elles font chuter le coût marginal de l’attaque.

Les « rogue AI » ne racontent pas toutes la même histoire

En juillet 2026, pendant des évaluations internes de cybersécurité, des modèles d’OpenAI ont contourné les mécanismes censés les isoler d’Internet, exploité des vulnérabilités dans une infrastructure partagée et accédé à des systèmes tiers, dont ceux de Hugging Face. OpenAI précise que les modèles fonctionnaient avec des garde-fousRègles et filtres (policy, classifiers, allowlists) qui limitent les sorties ou actions dangereuses d’un système IA. réduits dans le cadre de ces évaluations et que l’incident a été principalement provoqué par un modèle de recherche interne très performant.

Le 16 septembre, OpenAI a ensuite publié un cadre formel de signalement des comportements de « misalignment » accompagné de six rapports sur des comportements inattendus ou préoccupants observés au cours des six mois précédents.

Les trois incidents publiés par Anthropic le 30 juillet sont différents et méritent de rester séparés du cas OpenAI. Lors d’évaluations cyber menées avec un partenaire tiers, une mauvaise configuration avait laissé un accès Internet réel ouvert, alors que le promptConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils). indiquait aux modèles Claude qu’Internet n’était pas accessible. Chargés de trouver un « flag » dans un exercice de type capture-the-flag, les modèles ont donc interprété les systèmes réels rencontrés comme des éléments de la simulation et trois organisations ont subi des accès non autorisés.

Anthropic souligne explicitement que ses modèles n’ont pas exploité une vulnérabilité pour s’évader d’un confinement, contrairement au cas OpenAI. L’entreprise classe ces incidents plus près d’une défaillance de harnais et d’opérations que d’un problème d’alignement ; elle note aussi que le modèle le plus récent a cessé de poursuivre l’objectif après avoir compris qu’il se trouvait dans un environnement réel.

Les deux affaires ne démontrent donc pas la même chose. OpenAI documente un contournement actif du confinement. Anthropic montre à quel point une configuration incohérente entre les instructions données au modèle et les permissions réelles peut suffire à produire un incident.

C’est justement ce qui rend la formule de Kilo utile : le problème ressemble moins à une conscience hostile qu’à un exécutant extrêmement rapide auquel des objectifs, des permissions ou des contraintes ont été mal spécifiés.

Trois phénomènes qu’il ne faut surtout pas confondre

Le débat actuel mélange facilement trois choses.

La première concerne les agents qui agissent hors du périmètre prévu pendant des tests ou des tâches légitimes. Cela peut venir d’un contournement réel des barrières, comme chez OpenAI, ou d’un environnement mal configuré, comme dans les incidents Anthropic.

La deuxième concerne des humains malveillants qui utilisent volontairement des modèles comme multiplicateurs de force. Ici, les preuves commencent à devenir nombreuses.

La troisième, plus ancienne, reste l’automatisation classique du cybercrime : scanners Internet, botnets, frameworks d’exploitation, templates Nuclei, scripts de patch-diffing. Elle existait bien avant les LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. et suffit à expliquer une partie de l’explosion très rapide du trafic après la publication d’une faille.

Tout ranger sous l’étiquette « hacking par l’IA » ferait précisément disparaître ce qui est nouveau.

L’IA offensive n’est plus une hypothèse

En mai 2026, Google Threat Intelligence écrivait observer une transition vers une « application à échelle industrielle » des modèles génératifs dans les workflows adverses. Le groupe dit avoir identifié, pour la première fois, un acteur utilisant un zero-day qu’il estime avoir été développé avec l’aide d’une IA. Google documente également des usages pour la recherche de vulnérabilités, la génération d’exploits, l’obfuscation de malware et l’orchestration d’attaques.

Microsoft décrit de son côté l’IA comme un multiplicateur qui réduit la friction technique dans la reconnaissance, le social engineering, le développement de malware et les opérations après compromission. Mais son rapport de mars 2026 apporte une nuance importante : Microsoft observait alors des expérimentations précoces avec l’IA agentique, pas encore un usage agentique à grande échelle, notamment en raison de problèmes de fiabilité et de risque opérationnel.

Anthropic décrit un stade plus avancé dans son rapport de septembre 2026 : des frameworks multi-agents exécutent reconnaissance, exploitation et vol de données en parallèle, parfois avec très peu d’intervention humaine pendant des heures ou des jours — tout en précisant que les humains restent fortement impliqués dans le choix des cibles, la monétisation des résultats et leur revue.

La formulation d’Anthropic est probablement la plus utile pour comprendre le basculement : les techniques ne sont pas forcément nouvelles. Ce sont les coûts de main-d’œuvre, la vitesse et la capacité à paralléliser qui changent.

WordPress apparaît directement dans les rapports

Le cas GTG-50029 d’Anthropic donne à ce rapprochement une dimension très concrète. Au printemps 2026, un acteur francophone seul a utilisé Claude dans une campagne hacktiviste décrite par Anthropic, visant des partis politiques européens, des médias, des think tanks et les prestataires SaaSSoftware as a Service : logiciel livré en ligne par abonnement, multi-tenant en général. utilisés par ces organisations.

L’acteur s’appuyait sur les capacités de coding agentique de Claude et sur un framework pilotant des sous-agents chargés notamment de reconnaissance, de revue de code et de validation de résultats.

Sa technique d’accès initiale la plus caractéristique était une condition de course jusque-là non documentée dans le processus de réinstallation WordPress, permettant de créer un administrateur frauduleux sans identifiants valides. Anthropic indique que l’acteur a utilisé Claude pour développer et déboguer l’exploit au cours de la même session, avec un environnement de test, et que l’exploit a fonctionné contre au moins quatre sites victimes.

Il faut en revanche éviter de relier artificiellement tous les éléments techniques du rapport. Sur une autre cible, le même acteur a implanté un webshell caché parmi des fichiers de polices. Le rapport mentionne aussi l’utilisation d’un plugin WordPress « must-use » destiné à intercepter des identifiants. Enfin, Anthropic indique que des sauvegardes ont été empoisonnées, vraisemblablement afin de maintenir la persistance après restauration.

Ce cas n’est pas wp2shell. Mais il répond à une question centrale : il existe désormais un cas récent, documenté publiquement par un fournisseur de modèle, où un acteur a utilisé une IA pour construire et exploiter une technique WordPress inédite dans une campagne réelle.

wp2shell : une chaîne complète découverte avec une IA, mais une attribution partagée

Adam Kues, chercheur chez Searchlight Cyber, explique avoir pointé GPT-5.6 Sol Ultra sur le code de WordPress avec plusieurs agents et une consigne de chercher une chaîne pré-authentification vers RCE. Selon son récit, le modèle a d’abord découvert une injection SQL pré-authentification, puis construit la chaîne complète vers l’exécution de code. Le travail de l’IA a pris un peu plus de dix heures ; Kues estime le coût à environ 25 dollars, calculé au prorata de son abonnement à 200 dollars.

L’attribution officielle est toutefois partagée. WordPress 7.0.2 crédite Adam Kues pour la confusion de routes du batch REST menant au RCE, mais crédite séparément TF1T, dtro et haongo pour une « injection SQL facilitée », qui correspond selon toute vraisemblance à CVE-2026-60137 : c’est la seule faille touchant aussi la 6.8, ce que confirment l’annonce WordPress et l’analyse d’ELLIO. ELLIO précise par ailleurs que la chaîne wp2shell combine deux vulnérabilités : CVE-2026-63030, la confusion de routes, et CVE-2026-60137, l’injection SQL liée à author__not_in.

La formulation rigoureuse est donc la suivante : Adam Kues a découvert la chaîne complète avec GPT-5.6 Sol Ultra ; WordPress le crédite pour la confusion de routes menant au RCE, tandis que l’injection SQL sous-jacente a aussi été signalée par une autre équipe. L’IA est bien présente dans l’histoire de wp2shell, du côté de la découverte responsable, mais rien ne permet d’attribuer à l’IA la campagne d’exploitation qui a suivi.

Moins de 48 heures entre le patch et l’exploitation de masse

Le 17 juillet 2026, WordPress publie la version 7.0.2. La gravité est suffisante pour que le projet active des mises à jour forcées sur les versions concernées.

Le réseau de leurres d’ELLIO observe le premier probe le lendemain matin, à 08:12 UTC. Le 19 juillet entre 00:00 et 03:00 UTC, il enregistre déjà 2 055 sessions en trois heures. Entre le 18 et le 21 juillet, ELLIO comptabilise plus de 11 500 sessions, provenant de 241 adresses IP, sur 700 capteurs.

Le détail est important : toutes ces sessions ne correspondent pas à des compromissions réussies. ELLIO classe environ 5 000 sessions comme découverte de l’endpoint et validation de route, 3 900 comme confirmation d’injection SQL, 2 500 comme extraction de schéma ou de données, 54 comme extraction ciblée d’identifiants et de rôles, 20 comme tentatives de création d’administrateur et seulement deux comme tentatives d’écriture de webshell.

Autrement dit, la vague est massive, mais sa profondeur varie énormément. Ce que les données établissent avec certitude, c’est la vitesse à laquelle un correctif public peut devenir la matière première d’une campagne automatisée mondiale.

Une semaine n’est déjà plus un délai de sécurité

Le scénario se répète fin septembre avec CVE-2026-87902.

Le 22 septembre, WordPress publie 7.1.2 pour corriger une vulnérabilité de traversée de chemin pouvant conduire, sous certaines conditions, à l’inclusion d’un fichier PHP local puis à l’exécution de code. Patchstack indique que les versions 4.7.0 à 7.1.1 sont concernées. Le correctif existe dans 7.1.2, 7.0.6, 6.9.9, 6.8.10 et a été rétroporté jusqu’à 4.7.37.

Patchstack observe les premières tentatives à 11:49 UTC le 22 septembre, le jour même de la publication de 7.1.2.

À 15:34 UTC, Patchstack détecte une première tentative d’écriture de fichier via pearcmd. Le 23 septembre, les outils de scan publics comprennent déjà un template Nuclei nommé, et le volume atteint son pic autour de midi UTC.

Rien ne permet ici d’affirmer que l’IA a produit ces payloads. Patchstack note au contraire que leur encodage correspond exactement au correctif, ce qui pointe vers du patch-diffing. L’automatisation classique suffit techniquement à expliquer cette accélération.

Mais c’est précisément ce qui rend l’arrivée de l’IA intéressante : elle s’ajoute à une chaîne d’industrialisation qui était déjà extrêmement efficace.

Cinq heures : le chiffre qui change la façon de patcher

Le rapport annuel de Patchstack apporte une donnée plus générale que les exemples wp2shell ou CVE-2026-87902. Sur les vulnérabilités WordPress présentant les niveaux d’exploitation les plus élevés — un sous-ensemble représentant environ 95 % de l’activité d’exploitation observée sur les vulnérabilités publiées en 2025 — le délai médian pondéré avant la première exploitation est de cinq heures. Environ la moitié des vulnérabilités à fort impact sont exploitées en moins de 24 heures.

Cette mesure ne prouve aucun lien de cause à effet avec l’IA. Elle établit simplement la fenêtre opérationnelle dans laquelle défenseurs et attaquants travaillent désormais.

Patchstack a par ailleurs recensé 11 334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, soit 42 % de plus qu’en 2024, dont 1 966 classées à haut risque. Mais la hausse des vulnérabilités graves provient largement des composants premium et des marketplaces associées. Le core WordPress n’a compté que six vulnérabilités signalées en 2025, toutes classées à faible priorité.

Ces chiffres mesurent des vulnérabilités découvertes, pas le nombre global d’attaques. Ils ne permettent donc toujours pas de conclure à une croissance exponentielle du hacking WordPress.

« Exponentiel » ? Le mot va trop loin pour l’instant

Notre expérience récente avec plusieurs WordPress nous a donné le sentiment d’une accélération des compromissions, des scans et des tentatives de persistance. Cette observation de terrain est locale et ne constitue pas une statistique du marché.

Les données publiques permettent en revanche d’établir deux choses : certaines campagnes connaissent des hausses extrêmement brutales, et le délai entre divulgation et première exploitation peut désormais se compter en heures.

La formulation la plus rigoureuse reste donc : les données ne démontrent pas une croissance exponentielle générale, mais elles démontrent des épisodes d’exploitation beaucoup plus rapides et fortement industrialisés.

Le vrai changement : l’économie de l’attaque

C’est ici que les deux histoires — rogue agents et vagues de hacking — se rejoignent vraiment.

Un agent qui franchit une limite dans une évaluation et un attaquant qui lui demande de scanner WordPress ne constituent pas le même phénomène. Mais l’agentisation apporte à l’un comme à l’autre une propriété nouvelle à grande échelle : la capacité d’enchaîner des actions, d’observer un résultat, d’adapter le comportement et de recommencer sans attendre qu’un humain écrive chaque commande.

Pour un attaquant, cela transforme l’équation.

Un patch public devient une matière première. Un agent peut aider à lire le diff, identifier le chemin intéressant, produire un test, lancer des validations en parallèle, classer les réponses, générer un outil spécifique puis concentrer l’intervention humaine sur les cibles qui ont réellement répondu.

Google documente déjà des usages avancés allant jusqu’au développement assisté de zero-days ; Anthropic décrit des campagnes multi-agents menant reconnaissance, exploitation et vol en parallèle. Microsoft observe la même direction générale, tout en précisant qu’en mars 2026 l’usage agentique offensif restait encore expérimental et non déployé à grande échelle dans ses observations.

Anthropic résume le changement en termes économiques : le travail qui distinguait autrefois les opérations très dotées — reconnaissance, exploitation, développement d’outils, traitement de données — peut maintenant être délégué à des modèles fonctionnant à vitesse machine et en parallèle.

Ce n’est pas Skynet. C’est plus banal — et plus immédiatement problématique : un hacker peut désormais avoir une équipe de juniors qui ne dort jamais.

La course fonctionne aussi dans l’autre sens

wp2shell illustre presque parfaitement la symétrie du phénomène. La même histoire contient une découverte responsable de la chaîne complète accélérée par l’IA, parallèlement à un signalement indépendant de l’injection SQL sous-jacente, puis un patch rapide et une campagne d’exploitation automatisée dont aucune source fiable n’établit qu’elle ait elle-même été produite par une IA.

Google utilise de son côté des agents comme Big Sleep pour la découverte de vulnérabilités et CodeMender pour automatiser une partie de leur correction. L’accélération ne bénéficie donc pas uniquement aux attaquants.

Le problème est moins « l’IA donne l’avantage aux hackers » qu’une accélération générale de la boucle offensive et défensive.

Pour les équipes qui exploitent des sites WordPress, la conséquence est déjà concrète : le temps de réaction doit désormais se compter en heures, pas en jours. Les mises à jour de sécurité automatiques, la télémétrie, la surveillance des comptes administrateurs, des plugins must-use, des nouveaux fichiers PHP et des sauvegardes deviennent la manière normale d’opérer dans un environnement où la fenêtre entre divulgation et exploitation peut tomber à quelques heures.

La vraie bascule n’est peut-être donc pas une vague de « rogue AI » qui se mettrait spontanément à hacker Internet. Elle est beaucoup plus prosaïque : la recherche de vulnérabilités, l’exploitation et la défense sont toutes en train de devenir des workflows agentiques, et la vitesse humaine n’est plus l’unité de mesure de la course.