Le 17 juillet 2026, WordPress a publié les versions 6.9.5 et 7.0.2 pour corriger deux vulnérabilités du cœur, désormais regroupées sous le nom wp2shell. Quatre jours plus tard, le 21 juillet, l’agence américaine de cybersécurité CISA a ajouté l’une d’elles à son catalogue des vulnérabilités activement exploitées, confirmant que des attaquants s’en servent déjà contre des sites en production.
Ce qui distingue wp2shell de la plupart des alertes de sécurité WordPress, c’est son emplacement : dans le cœur de WordPress lui-même, pas dans une extension, et son déclenchement ne demande aucun mot de passe. Nous avons recoupé les rapports techniques, les notes de version et les analyses d’exploitation parues depuis pour vous donner une vision claire de ce qui s’est passé et de ce qu’il faut faire.
Qu’est-ce que wp2shell, précisément ?
wp2shell combine deux bugs distincts du cœur de WordPress en une seule chaîne d’attaque. Le premier, CVE-2026-63030, se situe dans le point d’entrée « batch » de l’API REST (/wp-json/batch/v1), la porte par laquelle WordPress traite plusieurs requêtes API en un seul appel. Une erreur d’analyse dans ce point d’entrée désynchronise deux listes de suivi internes, si bien qu’une requête finit traitée par le mauvais contrôle de permission. Le second, CVE-2026-60137, est une injection SQL dans le paramètre author__not_in de WP_Query : lui transmettre une chaîne de caractères au lieu du tableau attendu par WordPress suffit à contourner la validation.
Pris isolément, aucun des deux bugs n’est catastrophique. Chaînés, la confusion de route retire le contrôle d’authentification qui bloquerait normalement l’injection : un visiteur anonyme peut alors injecter sa requête SQL directement dans la base de données, puis exécuter son propre code sur le serveur.
Faut-il une extension ou un mot de passe pour être exposé ?
Non. wp2shell atteint une installation WordPress de base, sans aucune extension active et sans identifiants. Adam Kues, chercheur chez Assetnote (la division surface d’attaque de Searchlight Cyber) qui a signalé le bug de confusion de route, la décrit comme ne nécessitant aucune précondition : tout site sur une version de cœur affectée est exposé, équipe éditoriale ou non, chargé d’extensions ou non.
Ce qui a changé depuis le correctif : une exploitation confirmée
Quand The Hacker News a couvert wp2shell le 17 juillet, aucune exploitation n’avait encore été signalée. La situation a changé en quelques jours à peine. Le classement de la CISA au 21 juillet confirme un usage actif sur le terrain, et l’éditeur de sécurité Wiz a depuis publié des preuves concrètes de ce que font les attaquants une fois entrés : ils déposent de petites portes dérobées en PHP (Wiz a trouvé des exemples aussi simples que eval($_POST['[REDACTED]']??'http_response_code(404);')), installent un webshell déguisé de 150 Ko présenté comme une extension nommée « CMSmap », et enregistrent un faux point d’entrée REST pour exécuter des commandes encodées en base64. Wiz a également observé des attaquants se servir de la faille pour lister l’ensemble des comptes utilisateurs et sonder la présence du fichier wp-config.php, qui contient les identifiants de connexion à la base de données.
Ce même rapport estime qu’environ 60 % des installations WordPress passées au crible portaient encore au moins une version vulnérable le jour de la sortie du correctif, une part tombée à environ 50 % en 24 heures. Le balayage massif des sites non corrigés a donc commencé presque immédiatement après la divulgation.
Votre site est-il concerné ?
Cela dépend de la branche que vous utilisez.
- WordPress 6.8.0 à 6.8.5 : exposé à l’injection SQL seule, corrigée en 6.8.6.
- WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 : exposé à la chaîne complète d’exécution de code non authentifiée, corrigée respectivement en 6.9.5 et 7.0.2.
- WordPress 7.1 beta2 embarque déjà les deux correctifs.
Un détail réduit le risque sans l’annuler : selon l’analyse de Cloudflare, l’étape d’exécution de code ne fonctionne que si le site ne fait pas tourner de cache d’objets persistant. Searchlight Cyber ne traite pourtant pas ce détail comme un filet de sécurité dans son propre avis : l’injection SQL, elle, n’est pas affectée par cette condition, et l’avis continue d’appeler à une mise à jour immédiate.
Que faire maintenant, dans l’ordre
- Vérifiez votre version (Tableau de bord > Mises à jour) et passez en 6.9.5, 7.0.2 ou 6.8.6 selon votre branche.
- Ne présumez pas que la mise à jour forcée a déjà tout réglé si vous avez désactivé les mises à jour automatiques : WordPress n’a pas précisé si le déploiement forcé prévu pour cette version atteint les sites où elles sont coupées. Vérifiez donc manuellement si c’est votre cas.
- Si une mise à jour immédiate est impossible, Searchlight Cyber recommande de bloquer les requêtes vers
/wp-json/batch/v1(et sa forme?rest_route=/batch/v1) au niveau de votre pare-feu, ou d’installer une extension qui désactive l’API REST pour les visiteurs anonymes. Searchlight Cyber est explicite : ce sont des solutions de contournement, qui peuvent casser des intégrations légitimes et ne remplacent en rien la mise à jour. - Si votre site était accessible et non corrigé entre le 17 et le 21 juillet, recherchez des signes de compromission : extensions inconnues (Wiz en a repéré une déguisée en « CMSmap »), comptes administrateurs inattendus, ou fichiers PHP que vous n’avez pas créés. L’outil gratuit d’Assetnote, sur wp2shell.com, indique si un site est actuellement vulnérable, mais ne peut pas dire s’il a déjà été compromis par le passé.
Notre avis sur wp2shell
La plupart des alertes de sécurité WordPress remontent à une extension. wp2shell remonte à WordPress lui-même, et atteint par défaut chaque site sur une version affectée, chargé d’extensions ou non. Notre conseil habituel est de tester une nouvelle version sur un environnement de préproduction avant de toucher au site en ligne. Pour un correctif de cette urgence, nous garderions tout de même une sauvegarde récente avant de mettre à jour, mais nous ne retarderions pas la mise à jour elle-même pour vérifier la compatibilité : avec une exploitation active déjà confirmée, appliquer le correctif vient d’abord, la vérification de vos thèmes et extensions vient juste après. Si vous ne savez pas quelle version tourne sur votre site, c’est la première chose à vérifier dès aujourd’hui.
Si vous n’avez pas encore lu notre tour d’horizon de WordPress 7.0 « Armstrong », c’est le bon moment : il couvre justement la version que wp2shell affecte.
Sources : WordPress.org (notes de version officielles 6.9.5/7.0.2), fiche NVD/CVE pour CVE-2026-63030 et CVE-2026-60137, catalogue CISA des vulnérabilités activement exploitées, avis de recherche Searchlight Cyber / Assetnote, recherche de menaces Wiz.
