À la une
WP2Shell : la faille WordPress qui ouvre la porte aux pirates sans mot de passe
Deux vulnérabilités dans le cœur de WordPress peuvent permettre à un pirate de créer un compte administrateur et d’exécuter du code à distance. Voici les versions concernées et les mesures à prendre immédiatement.
Une chaîne de vulnérabilités critiques touche directement le cœur de WordPress. Pas besoin de compte administrateur, de mot de passe volé ou de plugin obscur abandonné depuis 2017 : sur certaines versions, quelques requêtes spécialement préparées peuvent suffire à prendre le contrôle du site. Et comme les exploits circulent désormais publiquement, il est vraiment temps de vérifier vos mises à jour.
Lorsqu’une grosse faille WordPress apparaît, le coupable est généralement assez facile à deviner : un plugin installé pour ajouter des flocons de neige à Noël, jamais mis à jour depuis trois ans, et dont le développeur a probablement changé de métier entre-temps.
Cette fois, le problème est nettement plus sérieux.
L’attaque baptisée WP2Shell vise directement le cœur de WordPress. Elle combine deux vulnérabilités permettant, dans certaines conditions, à un attaquant non authentifié de créer un compte administrateur, de se connecter au tableau de bord et d’exécuter du code sur le serveur.
Autrement dit : pas besoin de connaître votre mot de passe. Pas besoin non plus que vous cliquiez sur une pièce jointe intitulée facture_urgente_finale_v2.exe.
La porte peut s’ouvrir directement depuis Internet.
Deux failles qui font très mauvais ménage
WP2Shell repose sur l’enchaînement de deux vulnérabilités distinctes :
- CVE-2026-63030, une confusion dans le traitement des routes de l’API REST Batch de WordPress ;
-
CVE-2026-60137, une injection SQL liée au paramètre
author__not_inutilisé parWP_Query.
La première faille touche le mécanisme permettant d’envoyer plusieurs requêtes à l’API REST en une seule fois, via l’adresse :
/wp-json/batch/v1
Un problème de synchronisation entre la validation des requêtes et leur exécution peut conduire WordPress à traiter certaines opérations avec le mauvais gestionnaire.
La seconde vulnérabilité permet d’injecter du contenu dans une requête SQL. Normalement, les mécanismes de validation de WordPress doivent bloquer ce type de manipulation. Mais la confusion créée par la première faille permet justement de contourner certaines de ces protections.
En combinant les deux bugs, un attaquant peut extraire ou manipuler des informations dans la base de données, créer un utilisateur disposant des droits administrateur, puis téléverser une extension malveillante afin d’exécuter du code PHP sur le serveur.
Individuellement, ces failles sont déjà franchement désagréables. Ensemble, elles forment le genre de combo que l’on préférerait voir dans Street Fighter plutôt que sur un serveur de production.
Quelles versions de WordPress sont concernées ?
La chaîne complète permettant une exécution de code à distance concerne les versions suivantes :
- WordPress 6.9.0 à 6.9.4 ;
- WordPress 7.0.0 à 7.0.1.
Les correctifs sont disponibles dans :
- WordPress 6.9.5 ;
- WordPress 7.0.2.
La branche WordPress 6.8 n’est pas concernée par l’intégralité de la chaîne WP2Shell, mais elle reste touchée par l’injection SQL CVE-2026-60137. Les utilisateurs de cette branche doivent donc installer au minimum WordPress 6.8.6.
Les versions antérieures à WordPress 6.8 ne sont pas concernées par ces deux vulnérabilités. La version bêta de WordPress 7.1 a également été corrigée avec la Beta 2.
Voici le résumé sans caféine :
| Version installéeSituationVersion corrigée | ||
| Avant WordPress 6.8 | Non concernée par ces failles | — |
| WordPress 6.8 à 6.8.5 | Injection SQL possible | 6.8.6 |
| WordPress 6.9.0 à 6.9.4 | Chaîne WP2Shell complète | 6.9.5 |
| WordPress 7.0.0 à 7.0.1 | Chaîne WP2Shell complète | 7.0.2 |
Ce n’est plus seulement une démonstration de chercheurs
Au moment de la divulgation initiale, les chercheurs de Searchlight Cyber avaient volontairement conservé une partie des détails techniques afin de laisser aux administrateurs le temps d’installer les correctifs.
Cette période de tranquillité relative est désormais terminée.
Des preuves de concept publiques sont disponibles et les deux vulnérabilités ont été ajoutées, le 21 juillet 2026, au catalogue des failles activement exploitées de la CISA américaine. Rapid7 recommande donc non seulement d’installer le correctif, mais également de rechercher d’éventuels signes de compromission sur les sites qui étaient exposés.
Traduction pour les personnes qui administrent leur WordPress uniquement lorsque quelque chose casse : mettre à jour maintenant ne garantit pas que personne n’est passé avant vous.
Le patch ferme la porte, mais il ne fait pas automatiquement sortir quelqu’un qui serait déjà entré.
WordPress a déclenché des mises à jour forcées
Face à la gravité de la situation, l’équipe de sécurité de WordPress a activé les mises à jour automatiques forcées pour les installations concernées et compatibles avec le système de mise à jour en arrière-plan.
De nombreux sites ont donc probablement déjà reçu le correctif automatiquement.
Probablement.
Et c’est précisément le mot qui doit vous inquiéter.
Les mises à jour automatiques peuvent être désactivées dans la configuration de WordPress, bloquées par un hébergeur, interrompues par un problème de droits sur les fichiers ou échouer pour une multitude de raisons plus ou moins créatives.
Il ne faut donc pas simplement supposer que le site est à jour. Il faut ouvrir le tableau de bord et vérifier la version réellement installée. WordPress recommande officiellement une mise à jour immédiate vers les versions corrigées.
Que faire immédiatement ?
1. Vérifier la version de WordPress
Dans l’administration, rendez-vous dans :
Tableau de bord → Mises à jour
Vous pouvez également contrôler la version avec WP-CLI :
wp core version
Si votre installation utilise une version vulnérable, lancez immédiatement la mise à jour.
wp core update
Pensez évidemment à disposer d’une sauvegarde fonctionnelle des fichiers et de la base de données. Une sauvegarde que vous n’avez jamais essayé de restaurer reste une expérience philosophique, pas une stratégie de sécurité.
2. Ne pas se contenter du pare-feu
Cloudflare a déployé des règles WAF destinées à détecter et bloquer les tentatives d’exploitation des deux vulnérabilités. Elles sont proposées aux utilisateurs gratuits comme aux clients payants, à condition que le trafic du site passe réellement par le proxy Cloudflare.
Ces règles permettent de réduire les risques pendant le déploiement du correctif, mais elles ne réparent pas WordPress. La mise à jour reste la solution principale.
3. Bloquer temporairement l’API Batch
Lorsqu’une mise à jour immédiate est vraiment impossible, les chercheurs recommandent de bloquer provisoirement les accès anonymes aux chemins suivants au niveau du WAF :
/wp-json/batch/v1
?rest_route=/batch/v1
Cette mesure peut perturber certaines fonctionnalités légitimes utilisant l’API REST. Elle doit donc être considérée comme un pansement temporaire, et non comme une raison de repousser le patch jusqu’aux prochaines vacances.
4. Rechercher des traces de compromission
Les administrateurs ayant exposé une version vulnérable devraient examiner :
- les requêtes inhabituelles vers l’endpoint Batch dans les journaux HTTP ;
- les comptes administrateurs récemment créés ;
- les extensions inconnues ou installées sans raison ;
- les fichiers PHP récemment ajoutés ou modifiés ;
- les tâches planifiées suspectes ;
- les redirections, publicités ou pages inconnues apparues sur le site.
Rapid7 recommande explicitement d’effectuer ces vérifications même après l’installation du correctif, puisque des exploitations actives ont été signalées.
Un rappel utile pour tous les propriétaires de sites WordPress
WP2Shell illustre parfaitement une réalité que l’on oublie parfois : maintenir ses extensions ne suffit pas.
Il faut aussi mettre à jour :
- le cœur de WordPress ;
- les thèmes, même lorsqu’ils sont désactivés ;
- les plugins ;
- la version de PHP ;
- le système d’exploitation et les services du serveur ;
- les règles du pare-feu applicatif.
Ajoutez à cela des sauvegardes externalisées, une authentification multifacteur pour les comptes sensibles et une surveillance régulière des fichiers, et vous éviterez déjà une bonne partie des mauvaises surprises.
Aucune solution de sécurité ne rend un WordPress invulnérable. L’objectif est surtout d’empiler suffisamment de protections pour que les attaquants automatisés aillent casser les pieds à un serveur moins bien entretenu.
En résumé
WP2Shell n’est pas une énième faille touchant une obscure extension utilisée par douze personnes.
Elle affecte le cœur de WordPress et permet, sur certaines versions, une prise de contrôle à distance sans authentification. Les exploits sont publics, les vulnérabilités sont considérées comme activement exploitées et des correctifs sont disponibles.
La marche à suivre tient donc en trois lignes :
Vérifiez votre version. Installez WordPress 6.8.6, 6.9.5 ou 7.0.2 selon votre branche. Puis contrôlez les journaux, les administrateurs et les extensions de votre site.
Cela prend quelques minutes.
Reconstruire un serveur piraté, nettoyer du spam japonais dans 15 000 articles et expliquer à Google pourquoi votre blog de cuisine vend désormais de faux portefeuilles crypto prend généralement un peu plus de temps.
Communauté
Commentaires
Aucun commentaire pour le moment. Soyez le premier à réagir.