wp2shell : une RCE sur un WordPress standard, trouvée en dix heures pour 25 $

Le 17 juillet 2026, Searchlight Cyber a publié wp2shell, une chaîne d’exécution de code à distance avant authentification dans le cœur de WordPress qui ne nécessite ni extension, ni thème, ni connexion. Il suffit d’une requête anonyme contre une installation standard : « L’attaque n’a aucune condition préalable et peut être exploitée par un utilisateur anonyme dans une installation standard de WordPress sans aucune extension », indique l’avis de l’entreprise. La chaîne combine deux failles — CVE-2026-63030, une faille de confusion de route dans le point de terminaison batch de l’API REST de WordPress, que l’avis du projet qualifie de critique, et CVE-2026-60137, une injection SQL dans le paramètre author__not_in de WP_Query, que ce dernier qualifie de modérée. WordPress a publié WordPress 7.0.2 le jour même, et les avis du projet indiquent que WordPress 6.9.5, WordPress 6.8.6 et WordPress 7.1 beta2 contiennent les mêmes correctifs. Searchlight cite des estimations de plus de 500 millions de sites WordPress. Le chercheur à l’origine de la chaîne, Adam Kues, affirme qu’elle est issue d’une exécution de GPT-5.6 Sol Ultra construite à partir d’un prompt qu’OpenAI avait publié pour un problème de mathématiques : jusqu’à quatre agents, au moins six heures de recherche et environ quatre heures de plus pour l’escalade, pour environ 25 $ d’utilisation de modèle. Le dossier est consigné comme un résultat de recherche — une gravité élevée selon l’échelle propre à l’archive, une confiance de niveau A, aucun préjudice réel enregistré, daté d’une seule journée — et l’Orca AI Incident Archive le reprend avec les documents primaires liés en dessous.

La divulgation a été coordonnée. Searchlight a retenu les détails techniques le 17 juillet et a donné aux défenseurs le week-end pour mettre à jour ; Kues a publié le compte rendu technique complet le 20 juillet. À ce moment-là, l’exploit en chaîne avait déjà été reproduit indépendamment : Searchlight affirme que Calif et Hacktron ont reconstruit toute la chaîne avant que d’autres preuves de concept n’apparaissent sur GitHub. Les deux avis de sécurité de WordPress eux-mêmes citent les mêmes versions corrigées, et la CISA a ajouté les deux CVE à son catalogue Known Exploited Vulnerabilities le 21 juillet.

Deux bugs, et les tableaux qui se désynchronisent

Le point d’entrée est une fonctionnalité plutôt qu’une erreur. WordPress 5.6 a introduit le point de terminaison par lots en 2020 afin qu’un client puisse envoyer plusieurs requêtes REST virtuelles dans une seule requête HTTP, par exemple pour renommer un ensemble d’articles en une fois. Le point de terminaison est accessible que l’appelant soit authentifié ou non, et chaque sous-requête transporte l’authentification fournie par l’appelant. Une requête directe vers une route REST de WordPress exécute un pipeline en quatre étapes : vérifier les paramètres requis et valides, les assainir, exécuter le callback de permission, puis exécuter le callback du point de terminaison. Les points de terminaison s’appuient sur ce pipeline pour leurs hypothèses de type — qu’un ID d’article est un entier, qu’un titre est une chaîne.

L'API de traitement par lots divise le pipeline en deux, en validant chaque sous-requête dans une boucle et en les exécutant dans une seconde, et elle conserve deux tableaux, $matches et $validation, dont les entrées sont censées correspondre index pour index. Dans class-wp-rest-server.php, comme le décrit Kues, une sous-requête qui est elle-même une erreur WordPress est ajoutée à $validation puis rencontre un continue, sautant la ligne qui ajoute à $matches. À partir de ce moment, chaque correspondance est décalée d'une position vers l'arrière. La boucle d'exécution associe la sous-requête située à un index à la validation enregistrée à cet index, mais le gestionnaire est associé à une autre route — ainsi un paramètre est vérifié selon les règles d'un point de terminaison puis exécuté par le code d'un autre.

C’est ce qui transforme un paramètre de liste d’apparence ordinaire en injection. La route de collection des articles associe son argument public author_exclude à author__not_in. Lorsque la valeur est un tableau, WordPress applique absint à chaque élément et les trie ; lorsque la valeur est un scalaire, elle est concaténée telle quelle dans le fragment SQL qui devient NOT IN ($author__not_in). Une chaîne telle que 0) OR 1=1 -- se retrouve donc dans le texte de la requête. Appelée normalement, la route le refuserait, car author_exclude doit être un tableau d’entiers ; c’est l’appel par lots désynchronisé qui laisse passer une chaîne.

Deux obstacles subsistaient, et tous deux ont été résolus en imbriquant l’astuce. L’API par lots rejette les requêtes GET, et l’injection se trouve sur une route GET ; et la validation de la méthode de requête est elle-même mise en œuvre comme une validation de paramètre, que la même désynchronisation peut contourner. La charge utile publiée de Kues envoie une sous-requête externe malformée pour désynchroniser la vérification de la méthode, puis un lot interne dont la deuxième sous-requête transporte le malveillant author_exclude contre un gestionnaire qui ne le valide pas, puis la requête GET qui l’exécute. Une injection basée sur UNION renvoie des valeurs arbitraires de la base de données dans des lignes façonnées comme des articles ordinaires.

L'exécution du modèle : un prompt de maths, pointé vers une base de code

Kues n’a pas écrit le prompt de zéro. OpenAI avait publié le prompt qu’elle utilisait pendant ses travaux sur la conjecture du double recouvrement cyclique, et Kues a écrit qu’il avait lu que le modèle avait récemment résolu cette conjecture et que personne dans la communauté de la sécurité ne semblait parler du prompt. Son raisonnement était que si c’était assez bon pour des mathématiques difficiles, c’était probablement assez bon pour la recherche en sécurité. Il l’a adapté et l’a appliqué à WordPress.

La configuration était délibérément étroite. Il a cloné la dernière version stable de WordPress dans un répertoire appelé main/ et supprimé son répertoire .git, en demandant au modèle de ne pas utiliser les journaux de modifications, l’historique Git ou l’internet ouvert pour comparer le code à une version corrigée — sa raison déclarée étant que, pour la découverte de vulnérabilités inédites, consulter l’historique ou le web est une perte de tokens. Un répertoire vide third_party/ a été proposé afin que le modèle puisse cloner des dépendances telles que le code source de PHP ou MySQL s’il jugeait que la chaîne nécessitait des bogues dans les bibliothèques sous-jacentes à WordPress. La tâche était définie comme une RCE avant authentification dans un déploiement de production typique sur MySQL, avec jusqu’à quatre agents et au moins six heures. Kues a écrit qu’il énonce explicitement l’exigence de configuration parce que, sinon, les modèles « trichent » — en choisissant des options de configuration extrêmement improbables, ou en fabriquant des conditions préalables qu’un attaquant ne pourrait jamais atteindre.

Ce qui est revenu, dans la sortie en cours d’exécution, était une affirmation d’injection SQL avant authentification. Kues en doutait : WordPress figure parmi les cibles les plus auditées de tous les temps, écrivait-il, et n’avait pas eu de vulnérabilité significative avant authentification cette décennie-là. Il a installé une instance WordPress standard sur un serveur distant et a demandé au modèle de dérober l’adresse e-mail de l’administrateur ; en quelques minutes, il a imprimé l’adresse qu’il avait utilisée pour configurer l’instance. Il a ensuite demandé si l’injection en lecture seule pouvait être escaladée, et environ quatre heures plus tard, le modèle a répondu que oui — jusqu’à administrateur, sans casser aucun mot de passe et sans calcul hors ligne.

Son propre calcul : 50 % d’une allocation d’usage hebdomadaire, qu’il estimait à environ 25 $ au prorata d’un abonnement à 200 $, pour un exploit produit en un peu plus de dix heures. La part humaine n’était pas gratuite — Kues a passé la journée suivante à décortiquer ce que le modèle avait fait, et a écrit que le travail de post-exploitation lui avait pris beaucoup plus de temps à comprendre qu’il n’en avait fallu pour le générer. Son verdict est d’une franchise inhabituelle et strictement circonscrit : « Je ne formule aucune affirmation générale, mais je peux dire avec une confiance absolue qu’aucun chercheur en sécurité n’aurait pu trouver et mener à bien cette chaîne d’exploitation en 10 heures sans IA. »

D'un SELECT en lecture seule à administrateur

L’escalade est la partie du dossier qui compte le plus, car c’est là qu’une lecture de base de données s’est transformée en prise de contrôle du serveur. Le récit de Kues la déroule comme une séquence de six mouvements, chacun utilisant une fonctionnalité ordinaire de WordPress contre une autre.

Tout d’abord, empoisonnez le cache de publications en mémoire. WordPress conserve un cache par requête d’objets WP_Post afin que la même publication référencée plusieurs fois dans une requête ne coûte qu’un seul aller-retour à la base de données. L’injection SQL peut fabriquer des publications, de sorte que l’attaquant contrôle exactement ce qui est mis en cache — mais ces publications fabriquées ne sont pas des lignes dans la base de données, et le cache disparaît avec la requête.

Deuxièmement, transformez les articles fabriqués en lignes réelles.La fonction d’intégration de WordPress met en cache les intégrations résolues dans la base de données sous forme d’articles de type oembed_cache. Intégrer un article local par un chemin relatif, comme dans [embed]/?p=S[/embed], fait que WordPress évite la récupération HTTP et ne vérifie jamais que l’article référencé existe, si bien qu’une ligne est créée. Trois intégrations de ce type avec des jetons de chaîne de requête différents produisent trois hachages de cache différents, ce qui permet à l’attaquant d’obtenir plusieurs lignes avec lesquelles travailler.

Troisièmement, contournez le seul champ qui reste fixe. Lorsque les versions en mémoire et en base de données d'un article ne concordent pas, WordPress les réconcilie au moyen d'un appel qui définit explicitement post_content à partir de la sortie de l'intégration. Tout ce qui concerne l'article est contrôlé par l'attaquant, sauf son contenu, qui est précisément le champ qu'un customize_changeset utilise pour stocker le JSON des modifications de thème et de site en attente.

Quatrièmement, le gadget de cycle.Les publications ont des parents, et WordPress refuse les cycles : le wp_insert_post_parent filtre remonte l’arborescence et, lorsqu’il trouve une boucle, appelle une mise à jour qui définit post_parent à zéro. Cet appel n’écrase pas post_content, donc la version fabriquée en mémoire survit à la réconciliation — un changeset, avec son JSON intact, adossé à une véritable ligne.

Cinquièmement, emprunter l'autorité de l'administrateur. Un changeset dont le statut indique qu'il est planifié pour l'avenir mais dont la date est située dans le passé est appliqué immédiatement. Chaque entrée de son JSON nomme un user_id, et l'entrée dans la chaîne de Kues nomme user_id 1, l'administrateur, donc WordPress adopte temporairement cette identité pour appliquer la modification. La première modification est une mise à jour d'apparence inoffensive de nav_menus_created_posts.

Sixièmement, rejouez la requête en tant que cette identité. La publication d’un article déclenche une action nommée dynamiquement, {status}_{post_type}. Comme l’article est fabriqué, ce statut et ce type peuvent être n’importe quoi — y compris parse et request, ce qui produit le hook parse_request et redémarre le pipeline de requêtes depuis le début tandis que l’identité d’administrateur empruntée reste toujours en vigueur. La requête groupée originale contenait une sous-requête créant un nouvel administrateur ; elle a échoué lors du premier passage en tant qu’invité et réussit lors du rejeu. À partir de là, l’attaquant se connecte avec ce nouveau compte et téléverse un plugin de porte dérobée depuis un fichier ZIP, ce qui constitue une exécution de code.

La technique comporte une condition. Hacker News, citant Cloudflare, a rapporté que CVE-2026-63030 ne permet l’exécution de code à distance que lorsqu’un cache d’objets persistant n’est pas utilisé ; l’injection elle-même est présente depuis WordPress 6.8, tandis que la chaîne complète nécessite 6.9 ou une version ultérieure. Une installation standard n’a pas de cache d’objets persistant, ce qui explique pourquoi la formulation « sans conditions préalables » de Searchlight et la nuance de Cloudflare décrivent le même cas par défaut sous des angles différents.

Ce que les documents primaires établissent

Les avis publiés par WordPress lui-même constituent la corroboration la plus solide, car ils montrent l'éditeur reconnaissant les mécanismes en jeu et publiant le correctif. GHSA-ff9f-jf42-662q, classé critique, décrit une faiblesse de confusion de route par lots de l'API REST dans WordPress 6.9 et versions supérieures qui, combinée à l'injection, permet d'atteindre l'exécution de code, et en crédite Adam Kues d'Assetnote et Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, classé modéré, décrit l'injection author__not_in à partir de WordPress 6.8 et versions supérieures, et indique que les deux problèmes sont corrigés dans WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 et WordPress 7.1 bêta2. Les fiches NVD des deux CVE, notées par le CNA WPScan plutôt que par le NIST, attribuent 9,8 à CVE-2026-63030 avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, et 5,9 à CVE-2026-60137 avec AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — une faille joignable par le réseau et ne nécessitant aucun privilège dans le premier cas, et une faille exigeant une complexité d'attaque élevée et n'ayant qu'un impact sur la confidentialité dans le second. Le champ de gravité de l'archive pour cette entrée indique « high » (élevée) alors que WordPress qualifie la faille des lots de critique ; il s'agit de deux échelles distinctes appliquées à une chaîne complète et à un seul composant, et non d'un désaccord sur les failles elles-mêmes.

Les entrées du catalogue de la CISA, telles que reflétées dans les champs d'enrichissement de la NVD, ont été ajoutées le 21 juillet 2026, avec des échéances de remédiation fixées au 24 juillet pour CVE-2026-63030 et au 4 août pour CVE-2026-60137. La CISA nomme la première « WordPress Core Interpretation Conflict Vulnerability » et la seconde « WordPress Core SQL Injection Vulnerability ». Searchlight a également publié un outil de vérification public à l'adresse wp2shell.com afin que les opérateurs puissent tester une instance sans attendre la signature d'un scanner.

La reproduction indépendante est documentée par Searchlight elle-même et constitue donc une affirmation concernant des tiers plutôt qu’un compte rendu émanant d’un tiers : selon le compte rendu du 20 juillet, Calif et Hacktron ont reconstruit la chaîne complète avant que d’autres preuves de concept n’apparaissent sur GitHub. Ce qui est vérifiable indépendamment, c’est l’effet — preuves de concept, trafic d’exploitation et télémétrie des fournisseurs en quelques jours, détaillés ci-dessous.

Qu’est-ce qui est affirmé mais non établi ?

Deux attributions pour une seule injection ne concordent pas dans le dossier public. L’avis de WordPress pour CVE-2026-60137 indique que la vulnérabilité a été « découverte et divulguée de manière responsable en tant qu’équipe par TF1T, dtro et haongo ». Le compte rendu de Searchlight présente la même injection avant authentification que celle mise au jour par l’exécution de son modèle, et ne mentionne pas cette équipe ; l’avis de WordPress n’attribue à Kues que la confusion de route par lots, et ne mentionne aucun modèle. Aucun des deux documents n’explique le chevauchement, et rien de ce que cet article a pu trouver ne le résout — la possibilité que les deux aient été des découvertes indépendantes du même bug n’est pas exclue, et la possibilité qu’un rapport soit une redécouverte ultérieure n’est pas établie non plus. Le dossier ne tranche pas la question, et cet article non plus.

Le chiffre du titre de l'article de Searchlight du 20 juillet n'est pas étayé par le corps de l'article. On y lit : « Les courtiers en exploits paient {{1}}500 000 ${{/1}} pour une RCE WordPress. J'en ai trouvé une avec GPT5.6 Sol Ultra et {{2}}25 ${{/2}} ». Le corps de l'article documente précisément les {{3}}25 ${{/3}} et les dix heures ; il ne contient ni noms de courtiers, ni offres, ni correspondance, ni source pour le chiffre de {{4}}500 000 ${{/4}}. Aucun rapport indépendant repéré pour cet article ne corrobore un prix payé ou offert pour wp2shell. Interprétez le {{5}}500 000 ${{/5}} comme un cadrage du titre, et non comme un prix de marché établi.

La portée propre de l’entrée d’archive est plus étroite que l’histoire qui l’entoure. Elle consigne un résultat de recherche le jour de la divulgation, ne signale aucun dommage réel et est datée d’un seul jour, le 17 juillet 2026. Cela ne revient pas à affirmer que rien ne s’est produit par la suite : du trafic d’exploitation a été signalé dans les heures qui ont suivi l’avis, et la CISA a répertorié les deux CVE quatre jours plus tard. Le marqueur couvre ce que décrit l’entrée — la découverte et la divulgation coordonnée — et l’exploitation ultérieure est documentée par d’autres parties, sur la base de leurs propres éléments, ci-dessous.

Exploitation après l’avis

Jake Knott, chercheur principal en sécurité chez watchTowr, a déclaré à The Hacker News que « dès les premières heures de la matinée du samedi (UTC), l'exploitation réussie était déjà bien engagée, en utilisant d'abord du code d'exploit public pour exfiltrer des identifiants hachés, l'exécution de code à distance suivant une fois des détails supplémentaires rendus publics. » Le même rapport cite la télémétrie KEVIntel reliant 13 adresses IP uniques, provenant de Suisse, d'Allemagne, du Royaume-Uni, d'Indonésie, de Lituanie, des Pays-Bas et de Singapour, à l'exploitation de CVE-2026-63030, et cite Ryan Dewhurst, fondateur de KEVIntel, selon qui les requêtes correspondaient à des preuves de concept disponibles publiquement et où des charges utiles aveugles, basées sur UNION et basées sur booléen ont toutes été employées.

Les chercheurs de Wiz, Shahar Dorfman et Gili Tikochinski, dans une publication du 20 juillet, ont chiffré l'ampleur du phénomène : 60 % des organisations utilisant WordPress avaient au moins une instance vulnérable au moment de la publication des CVE et 25 % exposaient un serveur vulnérable sur Internet, ces chiffres tombant à 50 % et 10 % en 24 heures au fur et à mesure que les correctifs étaient appliqués. Ils ont relevé des téléversements malveillants de plugins via l'installateur d'administration, de l'énumération d'utilisateurs contre le point de terminaison users, des tentatives d'inclusion locale de fichiers visant wp-config, et des accès au panneau d'administration renvoyant HTTP 200 — la signature d'une connexion réussie plutôt que d'une sonde. Les logiciels malveillants qu'ils ont trouvés allaient d'une porte dérobée PHP minimale d'une seule ligne à un webshell de 150 Ko déguisé en plugin de sécurité WordPress légitime appelé CMSmap, avec des modules de gestion de fichiers, d'accès aux bases de données, de scan de ports et d'élévation de privilèges.

Wiz a également consigné une limite à ce qu’on peut en conclure. Un balayage à grand volume sans post-exploitation était courant, ce qui est compatible avec un scan massif opportuniste et avec un scan de sécurité légitime, et l’entreprise a déclaré qu’elle n’avait pas identifié de mouvement latéral ni d’exfiltration de données. Il s’agit d’une affirmation sur ce que la télémétrie d’un fournisseur a montré, et non d’une conclusion selon laquelle rien n’a été dérobé.

Qu’est-ce qui a changé par la suite, et qu’est-ce qui est resté en suspens ?

Pour les opérateurs, le chemin de réponse était court. La mise à jour vers WordPress 7.0.2, WordPress 6.9.5 ou WordPress 6.8.6 constitue le correctif. Les solutions d’urgence de Searchlight, pour les sites qui ne pouvaient pas être mis à jour immédiatement, consistaient à bloquer l’accès anonyme à l’API batch — soit en installant une extension qui bloque entièrement l’accès anonyme à l’API REST, soit en bloquant /wp-json/batch/v1 et ?rest_route=/batch/v1 au niveau d’un pare-feu d’applications web. L’entreprise a averti que ces deux mesures peuvent nuire à l’utilisation légitime du site et devraient être considérées comme des mesures temporaires jusqu’au déploiement de la mise à jour. Le vérificateur public sur wp2shell.com teste une instance directement. Les entrées du catalogue de la CISA ont ajouté une échéance de conformité : remédiation avant le 24 juillet pour CVE-2026-63030 et avant le 4 août pour CVE-2026-60137.

Pour la question de recherche, la partie qui n’a pas été résolue est ce que le modèle a réellement apporté par rapport à son opérateur. Kues est précis sur la répartition : le modèle a produit la chaîne d’exploitation en une dizaine d’heures, et il lui a fallu plus de temps pour la comprendre que pour la générer. Il refuse les affirmations générales et dit seulement que le résultat obtenu en dix heures n’était pas atteignable par un humain sans aide. Le prompt lui-même n’est pas un secret — il dérive d’un prompt publié par OpenAI, et Searchlight en a reproduit la structure dans son compte rendu, y compris l’instruction d’ignorer l’historique des versions et l’exigence que l’exploit fonctionne dans une configuration de production typique. La question de savoir si cette recette est transposable à d’autres bases de code est précisément celle à laquelle Kues dit qu’il ne répond pas, et aucune seconde exécution n’a été publiée.

Ce que le dossier laisse sans réponse est donc étroit, mais lourd de conséquences : laquelle des deux parties créditées a découvert l'injection la première, si un courtier a jamais payé le montant évoqué dans les gros titres, et ce que les webshells observés par Wiz ont réellement dérobé, le cas échéant, aux sites sur lesquels ils ont atterri. Sur ce dernier point, la seule déclaration publique est celle de Wiz : il n'a identifié aucun mouvement latéral ni exfiltration de données — une absence de preuve vue depuis un seul point d'observation, et présentée comme telle.