Faille WordPress wp2shell : le guide d'urgence (patch, détection, alternatives)

Le 17 juillet 2026, une faille critique a été divulguée et corrigée dans le cœur de WordPress. Elle porte un nom, wp2shell, et une particularité qui la rend sérieuse : là où une faille de plugin ne concerne que les sites qui l'ont installé, celle-ci vise WordPress lui-même et les touche donc presque tous. Le soir même du correctif, des attaques automatisées balayaient déjà le web à sa recherche.

Pas de panique. Si votre site tourne sur une version récente, l'essentiel du travail consiste à vérifier et à patcher. Voici, dans l'ordre, quoi faire.

La faille en clair

wp2shell enchaîne deux vulnérabilités :

• CVE-2026-60137 : une injection SQL dans le cœur de WordPress, via le paramètre author__not_in. En envoyant une chaîne de caractères là où le code attend un tableau, on contourne la validation.
• CVE-2026-63030 : une confusion de route sur l'endpoint REST /wp-json/batch/v1. Cet endpoint regroupe plusieurs requêtes en une seule. Une erreur volontaire dans une sous-requête décale d'un cran les tableaux de suivi internes, si bien qu'une requête finit exécutée sous le gestionnaire d'une autre et contourne la liste d'autorisations.

Mises bout à bout, ces deux failles laissent un attaquant non authentifié atteindre l'injection SQL, en extraire les empreintes (hashs) des mots de passe, les casser hors ligne, puis se connecter comme administrateur. La prise de contrôle demande donc plusieurs étapes, elle n'est pas immédiate.

%% Chaine d attaque wp2shell
flowchart TD
    A[Requete anonyme] --> B[Endpoint REST batch v1]
    B --> C[Confusion de route]
    C --> D[Contournement de l allow-list]
    D --> E[Parametre author__not_in mal valide]
    E --> F[Injection SQL non authentifiee]
    F --> G[Extraction des hashs de mots de passe]
    G --> H[Cassage hors-ligne]
    H --> I[Prise de controle du compte admin]

Les versions corrigées sont 6.8.6 (qui ne corrige que l'injection SQL, la chaîne complète n'existant qu'à partir de 6.9), 6.9.5 et 7.0.2. Les versions antérieures à 6.8 ne sont pas touchées. Un détail utile : les sites qui utilisent un cache objet persistant (Redis, Memcached) évitent le chemin le plus grave, mais restent exposés à l'injection SQL.

1. Patcher tout de suite

1. Vérifiez la version réellement installée, dans l'administration ou dans le fichier version.php. Ne partez pas du principe que l'auto-updater a tourné.
2. Passez à la version corrigée de votre branche : 6.8.6, 6.9.5 ou 7.0.2.
3. Si vous ne pouvez pas patcher tout de suite, bloquez au niveau du pare-feu applicatif (WAF) les deux chemins d'accès à l'endpoint vulnérable. C'est une mesure d'attente, qui peut casser des intégrations légitimes.

# Regle WAF: bloquer l acces anonyme au batch endpoint
location ~* /wp-json/batch/v1 { deny all; }
# Variante en query string
if ($args ~* "rest_route=/batch/v1") { return 403; }

2. Comment savoir si mon site est compromis

Cherchez les traces suivantes, en priorité sur la fenêtre entre la divulgation et votre correctif :

• des requêtes vers /wp-json/batch/v1 ou ?rest_route=/batch/v1 dans vos logs, surtout en pics de scan ;
• des erreurs SQL inhabituelles dans les logs, avec des morceaux de requête injectés ;
• des comptes administrateurs que vous ne reconnaissez pas ;
• des fichiers inconnus dans le dossier uploads, souvent des scripts PHP ;
• des modifications en base de données que vous n'expliquez pas.

Un seul de ces signaux mérite une inspection sérieuse.

3. Que faire en cas de compromission

Si vous avez un doute fondé, agissez comme si c'était avéré :

1. Isolez le site (mode maintenance ou coupure) pour stopper l'hémorragie.
2. Restaurez depuis une sauvegarde propre, antérieure à la fenêtre d'exposition.
3. Régénérez les clés et les sels (salts) dans wp-config.php, ce qui invalide toutes les sessions.
4. Réinitialisez tous les mots de passe, à commencer par les comptes administrateurs.
5. Auditez les comptes, les plugins et les tâches planifiées (cron), et supprimez ce qui n'a rien à faire là.
6. Scannez les fichiers à la recherche de portes dérobées.

4. Éviter que ça recommence

Les bons réflexes réduisent le risque sans le supprimer : activer les mises à jour, garder un WAF, appliquer le moindre privilège, et surtout réduire le nombre de plugins. Chaque extension est du code tiers que vous ne maîtrisez pas.

Il y a toutefois une limite à ce jeu. Vous patchez, une autre faille arrive, vous re-patchez. Pour beaucoup de sites vitrines, changer d'architecture devient plus efficace que de renforcer WordPress indéfiniment.

5. Les alternatives sécurisées à WordPress

Le point commun de ces alternatives : séparer l'endroit où l'on édite le contenu de celui qui sert les pages aux visiteurs. C'est une architecture découplée, aussi appelée headless.

• Les CMS headless (Payload, Strapi, Directus) gèrent le contenu via une API, sans exposer d'administration publique sur le site lui-même.
• Ghost couvre bien les besoins d'un site éditorial ou d'un blog.
• Les générateurs de sites statiques produisent des pages figées, sans base de données à attaquer côté public.
• Un front moderne (Next.js, TanStack Start) sert des pages pré-calculées et mises en cache, avec une surface d'attaque minimale.

6. Combien coûte une migration

Une migration n'est pas une refonte complète. Reprendre un site vitrine existant vers une stack découplée coûte en général de quelques centaines à quelques milliers d'euros, selon le nombre de pages, la complexité du design et les fonctionnalités à conserver. Le poste principal reste le contenu et les redirections, pour préserver votre référencement.

Si le sujet vous concerne, l'agence Platane (https://platane.io) migre les sites WordPress vers une stack sécurisée par conception, hébergée en haute disponibilité en France. On explique la démarche et les tarifs sur la page Migration WordPress.

Sources

• Rapid7, CVE-2026-63030 wp2shell
• Help Net Security, deux vulnérabilités WordPress
• The Hacker News, New wp2shell WordPress Core Flaw
• webhosting.today, unauthenticated path to code execution