TL;DR — « wp2shell » est le surnom d’une chaîne d’exploitation critique du cœur de WordPress, divulguée les 17-18 juillet 2026. Elle combine deux vulnérabilités : une injection SQL (CVE-2026-60137) et une confusion de route sur l’endpoint batch de la REST API (CVE-2026-63030). Prises séparément elles sont limitées ; chaînées, elles offrent une exécution de code à distance (RCE) sans authentification. Correctifs : WordPress 7.0.2, 6.9.5 et 6.8.6. Mettez à jour immédiatement.
Résumé exécutif
Le 17 juillet 2026, l’équipe de sécurité de WordPress a publié un avis (GitHub Security Advisory) décrivant une chaîne de vulnérabilités affectant le cœur du CMS. Le surnom « wp2shell » (littéralement « de WordPress au shell ») a été popularisé par les chercheurs de Searchlight Cyber. La particularité de cette chaîne : aucune des deux failles n’est catastrophique isolément, mais leur combinaison transforme un simple accès HTTP anonyme en compromission totale du site.
WordPress motorise une part majeure du web. Une RCE pré-authentification dans le core — et non dans un plugin tiers — concerne donc des millions d’installations. L’éditeur a déclenché des mises à jour forcées via le système d’auto-update, mais toutes les installations ne l’ont pas activé.
Versions affectées et corrigées
| Branche | Versions vulnérables | Version corrigée |
|---|---|---|
| 6.8.x | 6.8.0 → 6.8.5 | 6.8.6 |
| 6.9.x | 6.9.0 → 6.9.4 | 6.9.5 |
| 7.0.x | 7.0.0 → 7.0.1 | 7.0.2 |
| 7.1 (bêta) | Bêta 1 | 7.1 Bêta 2 |
Note : les versions antérieures à 6.8 ne sont pas concernées par CVE-2026-60137. CVE-2026-63030 touche les branches 6.9 et 7.0.
Anatomie de la chaîne
Maillon 1 — CVE-2026-60137 : injection SQL via author__not_in
Le premier maillon est une injection SQL dans le traitement du paramètre author__not_in de la classe WP_Query, le moteur central de requêtes de WordPress. Ce paramètre est censé recevoir une liste d’identifiants d’auteurs à exclure. Un défaut d’assainissement permet à une entrée contrôlée d’altérer la clause SQL générée.
Isolément, cette faille n’est atteignable que par un utilisateur authentifié disposant d’un contexte capable de passer ce paramètre : une blocklist interne du core empêchait qu’il soit atteint par une requête anonyme. C’est donc, seule, une vulnérabilité « post-auth », de sévérité élevée mais contenue.
Maillon 2 — CVE-2026-63030 : confusion de route sur la REST API batch
WordPress expose depuis plusieurs versions un endpoint batch (/wp-json/batch/v1) permettant de regrouper plusieurs appels REST en une seule requête, pour des raisons de performance. Le second maillon exploite une confusion dans la résolution des routes au sein de ce mécanisme : en encapsulant un appel dans une enveloppe batch, l’attaquant fait interpréter la sous-requête dans un contexte où les contrôles d’autorisation attendus ne s’appliquent pas de la même façon.
Autrement dit, CVE-2026-63030 sert de contournement d’authentification : il « débloque » la surface d’attaque qui était censée être réservée aux comptes légitimes.
Le chaînage
- L’attaquant enveloppe la requête vulnérable dans l’endpoint batch (CVE-2026-63030) pour contourner la blocklist qui réservait l’accès aux utilisateurs authentifiés.
- Cette enveloppe rend l’injection SQL
author__not_in(CVE-2026-60137) atteignable sans compte. - La SQLi permet d’exfiltrer des données sensibles de la base — typiquement des hachages de mots de passe administrateurs et des secrets d’authentification.
- À partir de là, l’attaquant obtient un accès administrateur (crack du hash, réutilisation de nonce/session, ou écriture directe), puis un webshell via un vecteur d’administration classique : d’où le « to shell ».
Un facteur aggravant a été relevé par Rapid7 : la surface est notamment atteignable lorsqu’aucun cache d’objets persistant (Redis/Memcached) n’est en place — c’est le cas de nombreuses installations par défaut.
Démonstration (environnement de laboratoire)
La section suivante décrit le déroulé conceptuel d’une reproduction en environnement isolé, à des fins de compréhension défensive. Les payloads d’attaque réels sont volontairement omis / caviardés (voir l’avertissement en fin d’article) : l’objectif est de comprendre le mécanisme et de savoir le détecter, pas de fournir un exploit clé en main alors que des millions de sites restent vulnérables.
1. Monter la cible
On déploie une version vulnérable connue (par ex. 7.0.1) dans un conteneur jetable, totalement coupé d’Internet, sans cache d’objets persistant :
# Réseau isolé, uniquement pour le labo — NE PAS exposer
docker network create --internal wp2shell-lab
docker run -d --name wplab-db --network wp2shell-lab
-e MYSQL_ROOT_PASSWORD=lab -e MYSQL_DATABASE=wp mysql:8
docker run -d --name wplab-web --network wp2shell-lab
-e WORDPRESS_DB_HOST=wplab-db -e WORDPRESS_DB_PASSWORD=lab
wordpress:7.0.1-php8.2-apache2. Observer la surface d’attaque
On confirme d’abord que l’endpoint batch répond, ce qui n’a rien d’anormal en soi :
# Requête bénigne, non exploitante — sert juste à cartographier la surface
curl -s http://wplab-web/wp-json/batch/v1 -X OPTIONS3. Le principe du contournement (caviardé)
Le cœur de l’exploitation consiste à soumettre au endpoint batch une enveloppe JSON contenant une sous-requête vers une route interne, dont le paramètre author__not_in transporte la charge d’injection. Structurellement :
POST /wp-json/batch/v1
Content-Type: application/json
{
"requests": [
{
"method": "POST",
"path": "/wp/v2/<route-interne>",
"body": {
"author__not_in": "<<< CHARGE SQLi CAVIARDÉE >>>"
}
}
]
}Les éléments réellement déterminants — la route interne exacte, la forme précise de la charge SQL et la technique d’extraction (union/blind/time-based) — ne sont pas reproduits ici. Ce qu’il faut retenir côté défense : une requête POST /wp-json/batch/v1 émanant d’un client non authentifié et embarquant un paramètre author__not_in non numérique est hautement suspecte.
4. Effet observé
Sur une cible vulnérable, la sous-requête est traitée sans le contrôle d’autorisation attendu et la clause SQL malformée est exécutée : on obtient une exfiltration de données depuis wp_users / wp_usermeta. Sur une cible patchée (7.0.2 / 6.9.5 / 6.8.6), la même requête est rejetée : le paramètre est correctement typé/assaini et l’enveloppe batch réapplique les contrôles d’autorisation. C’est exactement ce qui rend la mise à jour suffisante.
Détection et indicateurs
Aucun IoC officiel n’a été publié à la divulgation (pas d’exploitation in-the-wild confirmée au 17 juillet). Les signaux à surveiller côté journaux :
- Requêtes
POSTvers/wp-json/batch/v1— surtout sans cookie de session ni en-tête d’authentification. - Corps de requête contenant le paramètre
author__not_inavec une valeur non numérique (présence de guillemets, parenthèses, mots-clés SQL,SLEEP,UNION,SELECT…). - Pics de requêtes lentes vers la REST API (signature d’une SQLi time-based).
- Créations de comptes administrateurs, écritures de fichiers PHP dans
wp-content/uploadsou modifications de plugins/thèmes juste après.
Une règle de blocage périmétrique raisonnable (WAF / reverse proxy) consiste à rejeter les requêtes vers l’endpoint batch portant un author__not_in non strictement numérique, en attendant que la mise à jour soit confirmée partout. Cloudflare a d’ailleurs publié des règles WAF managées couvrant ces deux CVE.
Remédiation
- Mettre à jour le cœur vers 7.0.2, 6.9.5 ou 6.8.6 selon votre branche. C’est le seul correctif réel ; aucun workaround n’est recommandé à la place.
- Vérifier que l’auto-update a bien pris — ne pas supposer : contrôler la version effective (
Tableau de bord → Mises à jour, ouwp core version). Les installations avecDISALLOW_FILE_MODS, permissions restreintes ou auto-update désactivé n’ont pas reçu le correctif forcé. - En cas de doute sur une compromission : auditer les comptes administrateurs, les fichiers récemment modifiés, les tâches cron WordPress, et faire tourner un scanner (Wordfence / Sucuri). En cas de vol de hash, considérer les mots de passe et les salts (
wp-config.php) comme compromis : régénérer les clés et forcer la réinitialisation.
Divulgation responsable
Cet article est publié à des fins défensives et pédagogiques. Il s’appuie exclusivement sur des informations déjà rendues publiques par l’éditeur et des chercheurs reconnus (WordPress Security Team, Rapid7, VulnCheck, Searchlight Cyber, Cloudflare). Les détails d’exploitation réellement sensibles — route interne exacte, charge SQL fonctionnelle, technique d’extraction — sont délibérément omis tant qu’une large part du parc reste vulnérable. Toute reproduction doit se faire uniquement sur des systèmes vous appartenant, en environnement isolé. Attaquer un système tiers sans autorisation écrite est illégal.
À lire aussi
Pour durcir votre exposition en amont, voir aussi notre article : Installer et sécuriser Pangolin, reverse proxy auto-hébergé, sur Debian.
Sources
- NVD — CVE-2026-63030
- Rapid7 — wp2shell, Critical RCE in WordPress Core
- VulnCheck — WP2Shell (CVE-2026-60137 & CVE-2026-63030)
- The Hacker News — New wp2shell WordPress Core flaw
- Cloudflare — WAF protects WordPress applications from two high-severity vulnerabilities