CVE-2026-63030 (wp2shell) : faille RCE critique WordPress

Qu'est-ce que wp2shell (CVE-2026-63030) ?

wp2shell est le surnom donné à une chaîne d'exploitation critique publiée via une alerte de sécurité GitHub le 17 juillet 2026, qui permet à un attaquant non authentifié de prendre le contrôle total d'un site WordPress. Contrairement à la plupart des failles WordPress qui touchent un plugin ou un thème tiers, wp2shell se situe dans le cœur de WordPress lui-même (WordPress Core), ce qui la rend particulièrement dangereuse : elle concerne potentiellement toute installation sous WordPress 6.9 ou 7.0, quels que soient les extensions installées.

Si votre site WordPress n'a pas été mis à jour depuis le 17 juillet 2026, il est probablement temps de vérifier sa version immédiatement — l'explication complète et les étapes à suivre sont ci-dessous.

Comment fonctionne l'attaque : la chaîne wp2shell expliquée

wp2shell n'est pas une seule faille mais l'enchaînement de deux vulnérabilités distinctes, chacune inoffensive prise séparément, mais qui combinées permettent une prise de contrôle complète du site sans le moindre compte utilisateur.

Étape 1 — La confusion de route sur l'API REST (CVE-2026-63030)

WordPress expose un point de terminaison /wp-json/batch/v1 qui permet de regrouper plusieurs requêtes API en une seule. WordPress traite ces sous-requêtes dans des tableaux de suivi parallèles. Le problème (classé CWE-436, "Interpretation Conflict") : si l'une des sous-requêtes du lot provoque volontairement une erreur, les tableaux de suivi se désynchronisent d'une position. Les sous-requêtes suivantes s'exécutent alors sous le mauvais gestionnaire (handler) et donc avec les mauvaises vérifications de permissions.

Étape 2 — L'injection SQL dans WP_Query (CVE-2026-60137)

Le paramètre author__not_in de la classe WP_Query attend normalement un tableau de valeurs. En lui passant une chaîne de caractères au lieu d'un tableau, les contrôles de validation sont contournés et la valeur est injectée brute dans la requête SQL.

Étape 3 — L'enchaînement complet

1. L'attaquant envoie une requête batch malveillante à /wp-json/batch/v1, sans authentification
2. Une erreur volontaire dans une sous-requête désynchronise les tableaux de suivi de WordPress
3. Grâce à cette confusion, une sous-requête ultérieure atteint le paramètre vulnérable author__not_in sans passer par les vérifications de permissions normales
4. L'injection SQL s'exécute, ce qui permet in fine l'exécution de code arbitraire sur le serveur

Résultat : compromission complète du site (fichiers, base de données, création de comptes administrateur) sans qu'aucun mot de passe ni compte valide ne soit nécessaire.

CVE-2026-63030 vs CVE-2026-60137 : deux failles, une seule chaîne

Il est important de ne pas confondre les deux identifiants, car ils n'ont pas le même historique ni le même périmètre :

Autrement dit : les sites encore sous WordPress 6.8.x sont vulnérables à l'injection SQL seule (CVE-2026-60137), mais pas à la chaîne RCE complète puisque le point de terminaison batch vulnérable n'existait pas encore sous cette forme. La chaîne complète wp2shell ne touche que les installations sous 6.9.0-6.9.4 et 7.0.0-7.0.1, soit grosso modo les sites mis à jour entre décembre 2025 et juillet 2026.

Pourquoi le score de sévérité varie entre 7,5 et 9,8 ?

Deux organismes ont noté cette faille différemment, ce qui explique les chiffres contradictoires que vous verrez circuler :

• WPScan (CNA) : 9,8 / 10 – Critique. Vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — impact total sur la confidentialité, l'intégrité et la disponibilité, cohérent avec une RCE complète.
• CISA-ADP : 7,5 / 10 – Élevé. Vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — évaluation plus conservatrice qui ne retient que l'impact confidentialité.

Dans les deux cas : accès réseau, aucune authentification, aucune interaction utilisateur requise. Que le score retenu soit 7,5 ou 9,8, la faille reste exploitable à distance par n'importe qui — la correction doit être traitée en priorité maximale, indépendamment du chiffre affiché par votre scanner de vulnérabilités.

Exploitation active : où en est-on ?

Les informations sur ce point évoluent vite et divergent selon la source :

• Un proof-of-concept (PoC) public circule sur GitHub depuis la divulgation du 17 juillet 2026.
• Au 18 juillet 2026, la NVD et Rapid7 Labs n'avaient pas confirmé d'exploitation active recensée, tout en jugeant "hautement probable" une exploitation massive à très court terme compte tenu de la disponibilité du PoC.
• Plusieurs éditeurs de threat intelligence (dont Rescana) ont depuis émis des alertes évoquant une exploitation active "in the wild".
• WordPress a déclenché des mises à jour automatiques forcées pour les installations éligibles, signe de la gravité perçue par l'équipe core.

Un facteur atténuant a été identifié par Cloudflare : les sites utilisant un cache d'objet persistant (Redis ou Memcached) semblent bloquer ce chemin d'exploitation spécifique en tant qu'effet de bord — mais il ne s'agit pas d'une protection garantie ni d'un correctif, seulement d'une variable qui réduit la surface d'attaque sur certaines configurations.

Comment savoir si votre site WordPress est vulnérable

1. Vérifiez votre version WordPress dans Réglages → Général, ou via wp core version en ligne de commande si vous avez accès SSH/WP-CLI.
2. Si vous êtes en 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1 : votre site est vulnérable à la chaîne RCE complète.
3. Si vous êtes en 6.8.0 à 6.8.5 : vous êtes vulnérable à l'injection SQL seule (CVE-2026-60137), sans la partie RCE.
4. Vérifiez si un cache d'objet persistant (Redis, Memcached) est actif — cela ne remplace pas la mise à jour mais réduit le risque immédiat en attendant.

Comment se protéger dès maintenant

1. Mettez à jour immédiatement

La correction est simple et gratuite : passez à la version 6.9.5 (branche 6.9) ou 7.0.2 (branche 7.0). C'est la seule protection réellement définitive. Si les mises à jour automatiques sont désactivées sur votre site, WordPress recommande de les réactiver au moins temporairement.

2. En attendant la mise à jour : règle de pare-feu temporaire

Un blocage WAF ciblant le point de terminaison /wp-json/batch/v1 (et ses variantes en paramètre de requête) réduit le risque en attendant la mise à jour. Attention cependant : cette route est utilisée par certaines intégrations légitimes (éditeurs de blocs, applications mobiles), le blocage peut donc casser des fonctionnalités du site.

3. Activez un cache d'objet persistant

Redis ou Memcached ne corrigent pas la faille mais réduisent la probabilité d'exploitation réussie sur certaines configurations, en attendant que la mise à jour soit déployée.

4. Vérifiez l'absence de compromission

Si votre site tournait sous une version vulnérable avant que vous ne le mettiez à jour, vérifiez qu'aucun compte administrateur inconnu n'a été créé et qu'aucun fichier suspect n'a été déposé. Les signes d'un site déjà compromis sont détaillés dans notre guide sur le piratage WordPress.

Mon site a peut-être déjà été compromis, que faire ?

Si vous constatez un des signes de piratage (compte admin inconnu, redirections inattendues, alerte Google, e-mails spam envoyés depuis votre domaine) après avoir tourné sous une version vulnérable, ne vous contentez pas de mettre à jour : votre site a peut-être déjà été compromis avant le patch. Notre équipe propose une intervention d'urgence de nettoyage et réparation de site piraté, avec un délai d'intervention sous 4h en journée.

Ce que ça change pour votre stratégie de maintenance

wp2shell illustre exactement pourquoi une maintenance WordPress active a de la valeur : nos clients sous contrat n'ont pas eu à se poser la question de leur exposition le 17 juillet — leurs sites étaient déjà mis à jour et surveillés dans les heures suivant la divulgation. Une faille core comme celle-ci touche potentiellement des centaines de milliers de sites en quelques jours ; la vitesse de réaction fait toute la différence entre un correctif de routine et un nettoyage de site piraté en urgence.

Vérifier gratuitement si mon site est exposé à wp2shell →