wp2shell : exécution de code sans authentification dans WordPress et comment la bloquer

19 juillet 2026 Mise à jour 29 septembre 2026 Patrick Schlesinger

wp2shell est une chaîne d’exécution de code à distance sans authentification dans le cœur de WordPress, qui combine deux failles, CVE-2026-63030 et CVE-2026-60137. WordPress l’a corrigée le 17 juillet 2026 avec les versions 7.0.2, 6.9.5 et 6.8.6, et les premières attaques ont suivi en quelques heures.

Mettez d’abord à jour le cœur de WordPress, car seul le correctif supprime la faille. ReportedIP Hive bloque le schéma d’attaque sur toutes les formules, y compris la formule gratuite, depuis la version 2.1.25 du 19 juillet 2026. Cela protège les sites pas encore corrigés et bloque aussi les variantes de l’attaque.

Qu’est-ce que wp2shell ?

wp2shell désigne deux vulnérabilités du cœur de WordPress exploitées ensemble. Aucune des deux ne permet seule d’exécuter du code. Enchaînées, elles mènent une requête anonyme jusqu’à la création d’un nouveau compte administrateur.

CVE-2026-60137 (injection SQL). WordPress ne nettoie pas correctement le paramètre author__not_in de WP_Query. Dans l’API REST, il est alimenté par author_exclude. Seule, la faille n’est atteignable que si une extension ou un thème transmet des données non vérifiées à ce paramètre.
CVE-2026-63030 (confusion de routes dans le batch REST). Le point de terminaison /wp-json/batch/v1 valide puis distribue les sous-requêtes dans deux boucles séparées. Une sous-requête au chemin mal formé décale les deux listes, si bien qu’une requête s’exécute avec le gestionnaire d’une autre route. Le paramètre vulnérable atteint ainsi la requête des articles sans connexion.

Quelles versions de WordPress sont concernées ?

La confusion de routes est apparue avec WordPress 6.9, la chaîne complète ne fonctionne donc que sur 6.9 et 7.0. L’injection SQL seule remonte jusqu’à 6.8. Les notes de version de WordPress 7.0.2 détaillent les corrections.

Branche	Concernées	Corrigé dans	Chaîne complète
7.0	7.0.0 à 7.0.1	7.0.2	Oui
6.9	6.9.0 à 6.9.4	6.9.5	Oui
6.8	6.8.0 à 6.8.5	6.8.6	Non

WordPress.org a imposé la mise à jour aux sites concernés via le système de mises à jour automatiques. Les sites dont les mises à jour automatiques sont désactivées, ou dont l’hébergeur retient les mises à jour du cœur, restent exposés jusqu’à une mise à jour manuelle. La CISA a ajouté les deux CVE à son catalogue de vulnérabilités activement exploitées le 21 juillet 2026, et la fiche NVD de CVE-2026-63030 en suit les détails.

Comment l’attaque arrive-t-elle jusqu’au shell ?

Chaque étape de la chaîne est une requête POST vers le point de terminaison batch, envoyée soit à /wp-json/batch/v1, soit à ?rest_route=/batch/v1. Dans la requête, un sous-chemin mal formé provoque la confusion de routes et un batch imbriqué transporte l’injection SQL. L’injection lit des données dans la base, et les requêtes suivantes créent un nouvel administrateur via la route REST des utilisateurs. Avec un compte administrateur, l’envoi d’une extension donne à l’attaquant l’exécution de code sur le serveur.

Patchstack a observé les premières tentatives d’exploitation environ 90 minutes après la sortie de 7.0.2. Au 22 juillet 2026, Patchstack avait bloqué plus de 65 000 tentatives venant de plus de 1 500 adresses IP, dont 97 pour cent visaient le point de terminaison batch.

Combien d’attaques wp2shell ReportedIP observe-t-il ?

Nos serveurs honeypot reconnaissent les requêtes wp2shell comme un type d’attaque à part depuis le 5 septembre 2026. Du 5 au 28 septembre 2026, ils ont transmis 601 signalements concernant 347 adresses IP distinctes, soit 3 196 requêtes journalisées. 580 des 601 signalements contenaient le batch imbriqué dont l’attaque dépend. Le 29 septembre 2026, 51 des 347 adresses avaient un score de confiance de 75 ou plus, le seuil de la blacklist ReportedIP.

L’attaque continue plus de deux mois après le correctif. Les scanners testent chaque site WordPress qu’ils trouvent, parce que certains sites ne sont toujours pas corrigés. Le rapport d’attaques de mai à juillet couvre les semaines autour de la divulgation.

Comment ReportedIP Hive bloque-t-il wp2shell ?

Le pare-feu de Hive contrôle chaque requête des visiteurs non connectés. Il examine l’URL, le user agent et le corps de la requête avant que WordPress ne traite la requête. Avec l’Extended Protection activée, le contrôle a lieu avant même le chargement de WordPress. Depuis la version 2.1.25, le pare-feu lit le corps brut et décodé, si bien qu’une charge encodée dans un batch JSON reste visible pour les mêmes signatures.

La version 2.1.25 a ajouté deux règles qui visent la structure de l’attaque plutôt qu’un simple mot-clé :

waf_rest_batch_desync reconnaît les sous-chemins mal formés que l’analyseur batch rejette, par exemple plusieurs barres obliques en tête ou un schéma avec un hôte vide. Remplacer un chemin mal formé par un autre ne permet pas de passer.
waf_rest_batch_nested reconnaît une sous-requête dont le corps est lui-même un batch. L’attaque ne peut pas se passer de cette imbrication sans perdre la confusion de routes.
waf_sqli_union bloquait déjà avant 2.1.25 l’injection UNION SELECT dont dépend l’étape de création de l’administrateur.

Les trois règles font partie de la base gratuite livrée avec l’extension. Elles fonctionnent donc sur toutes les formules et sans synchronisation des règles. Les sites avec Priority Sync sur la formule Professional reçoivent les mêmes règles via la distribution signée et peuvent ajouter les signatures plus poussées des niveaux de paranoïa 2 et 3. Dans notre suite de tests, les appels batch normaux, les URL relatives au protocole et les URL absolues passent les deux règles batch. Le guide du pare-feu WordPress explique les niveaux de règles, les exceptions et la page de blocage.

Que doivent faire les administrateurs WordPress maintenant ?

Vérifiez la version du cœur sur chaque site et passez à 7.0.2, 6.9.5 ou 6.8.6 ou plus récent.
Cherchez des comptes administrateur que personne de votre équipe n’a créés, et des extensions que vous n’avez pas installées.
Mettez ReportedIP Hive à jour vers la version actuelle depuis Extensions, ou cliquez sur Vérifier les mises à jour dans la ligne de l’extension.
Sur les sites Professional, cliquez sur Sync now dans la page des règles pour récupérer tout de suite le jeu de règles actuel.

La documentation du pare-feu décrit la distribution des règles et comment autoriser une requête bloquée par erreur.

Questions fréquentes

ReportedIP Hive remplace-t-il la mise à jour du cœur de WordPress ?

Hive ne remplace pas la mise à jour du cœur, car seul le correctif supprime la faille. Le pare-feu bloque le schéma de requête avant qu’il n’atteigne le code vulnérable. Cela protège un site jusqu’à son correctif et bloque les variantes de l’attaque. Chaque site doit tout de même tourner sous WordPress 7.0.2, 6.9.5 ou 6.8.6 ou plus récent.

Les sites Hive gratuits sont-ils protégés contre wp2shell ?

Les sites gratuits sont protégés dès qu’ils utilisent Hive 2.1.25 ou plus récent. Les deux règles batch et la règle UNION SELECT font partie de la base livrée avec l’extension, il ne faut donc ni formule payante ni synchronisation des règles. La formule Professional ajoute des signatures plus poussées et des mises à jour quotidiennes des règles.

Les nouvelles règles bloquent-elles des requêtes batch REST légitimes ?

Les requêtes batch normales passent, car les règles ne reconnaissent que les sous-chemins mal formés et un batch imbriqué dans le corps d’une sous-requête. Les appels batch de l’éditeur de blocs n’ont aucune de ces formes. Si une extension de votre site en envoie une, vous pouvez créer une exception pour cette règle depuis l’Event Log de Hive.