WP2Shell : comment sécuriser WordPress avant la prise de contrôle sans plugin

Depuis le 17 juillet 2026, WordPress diffuse en urgence les versions 6.9.5 et 7.0.2 : elles corrigent WP2Shell, une chaîne d'exploitation qui permet de prendre le contrôle d'un site WordPress sans compte, sans mot de passe et sans le moindre plugin tiers installé. Un cas rare et sérieux, car cette fois la faille se loge directement dans le cœur du CMS, pas dans une extension oubliée depuis trois ans.

Si votre site tourne sous WordPress, voici ce que vous devez vérifier dans les prochaines minutes, et comment verrouiller votre configuration même après avoir patché.

Pourquoi WP2Shell change la donne

D'ordinaire, quand une alerte de sécurité touche WordPress, le coupable est un plugin tiers mal maintenu. Cette fois, rien de tout ça : WP2Shell enchaîne deux vulnérabilités situées dans le cœur même de WordPress.

• CVE-2026-63030 : une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1.
• CVE-2026-60137 : une injection SQL dans le paramètre author__not_in de WP_Query.

Prises séparément, chacune est déjà problématique. Enchaînées, elles offrent une exécution de code à distance (RCE) sans authentification préalable : quelques requêtes HTTP suffisent, sans compte, sans mot de passe, sans plugin exotique à exploiter.

Qui est concerné

La chaîne complète touche les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre installation se situe dans ces fourchettes, elle est exposée. Les correctifs sont disponibles depuis le 17 juillet 2026 avec les versions 6.9.5 et 7.0.2.

Si vous êtes encore sur une branche 6.8.x, seule l'injection SQL (CVE-2026-60137) vous concerne potentiellement : elle a été corrigée depuis la version 6.8.6. Sans le maillon de la confusion de route, la chaîne complète vers la RCE ne s'applique pas à ces versions.

Autre point à connaître : WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés, une mesure réservée aux failles jugées critiques. Il y a donc de bonnes chances que votre installation ait déjà reçu le correctif sans intervention de votre part. Mais ne comptez pas dessus : si les mises à jour automatiques sont désactivées sur votre hébergement (un choix fréquent chez de nombreux hébergeurs et administrateurs), rien n'aura été poussé chez vous.

Ce qu'il faut faire, dans l'ordre

Première chose, vérifiez votre version. En ligne de commande via WP-CLI :

wp core version

Si le résultat est inférieur à 6.9.5 (branche 6.9.x) ou 7.0.2 (branche 7.0.x), mettez à jour immédiatement :

wp core update
wp core update-db

Sans accès WP-CLI, la mise à jour se fait depuis l'administration WordPress, dans Tableau de bord puis Mises à jour. L'équipe à l'origine de la découverte a également mis en ligne un outil de vérification externe, wp2shell.com, qui permet de tester si un site est vulnérable sans y toucher.

En attendant le patch : bloquez l'endpoint batch

Si vous ne pouvez pas mettre à jour immédiatement (contrainte de compatibilité, site sous contrat de maintenance tiers, hébergement mutualisé figé), la parade défensive consiste à bloquer l'accès anonyme à l'endpoint REST batch. Deux formes à couvrir absolument, car l'une contourne l'autre si elle est oubliée :

• /wp-json/batch/v1
• ?rest_route=/batch/v1 (la variante en paramètre de requête)

Avec Nginx, un blocage simple au niveau du serveur :

location ~* ^/wp-json/batch/v1 {
    return 403;
}
if ($arg_rest_route ~* "^/batch/v1") {
    return 403;
}

Avec Apache, via .htaccess :

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/batch/v1 [OR]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1
RewriteRule ^ - [F,L]

Si votre site est derrière Cloudflare, des règles WAF prêtes à l'emploi sont disponibles pour couvrir cette faille sans toucher à la configuration serveur. Un plugin de sécurité WordPress à jour (pare-feu applicatif) peut aussi filtrer ces routes en attendant la mise à jour du cœur.

Le contexte technique, en bref

La découverte revient à Adam Kues, chercheur chez Assetnote (une entité de Searchlight Cyber), qui a assemblé et documenté la chaîne complète avant de la remonter via le programme HackerOne officiel de WordPress. Les chercheurs gardent volontairement sous le coude le détail exact du dernier maillon technique vers la RCE, le temps que l'écosystème se mette à jour. Un point de vigilance supplémentaire : un début de preuve de concept circule déjà publiquement, et des scans automatisés à grande échelle ont commencé sur le web. La fenêtre entre divulgation et exploitation massive se referme vite sur ce type de faille.

Avec plus de 500 millions de sites propulsés par WordPress dans le monde, même une fraction seulement exposée à cette chaîne représente une surface d'attaque considérable.

Notre lecture chez CZSyn

Ce type de faille rappelle une règle que nous répétons souvent à nos clients : la sécurité d'un site WordPress ne se limite pas à surveiller ses plugins. Le cœur du CMS, aussi robuste soit-il, reste un logiciel comme un autre, avec sa propre surface d'attaque. Une politique de mise à jour automatique désactivée « pour éviter les mauvaises surprises » se transforme, dans des cas comme WP2Shell, en fenêtre d'exposition de plusieurs semaines.

Pour une PME ou un indépendant qui gère son site sans équipe technique dédiée, trois réflexes limitent durablement ce genre de risque : garder les mises à jour automatiques activées sur le cœur WordPress, s'appuyer sur un pare-feu applicatif (Cloudflare ou plugin de sécurité) qui filtre les routes sensibles par défaut, et faire auditer sa configuration au moins une fois par an par un tiers. Le coût d'un audit est sans commune mesure avec celui d'un site compromis, revendu comme relais de spam ou de phishing pendant des semaines avant d'être repéré.

Sources primaires

• Searchlight Cyber / Assetnote, « WP2Shell: Pre-Authentication RCE in WordPress Core ».
• Rapid7, « ETR: CVE-2026-63030 WP2Shell, a critical remote code execution vulnerability in WordPress core ».
• Cloudflare, « WordPress vulnerabilities », règles WAF.
• Outil de vérification, wp2shell.com.