Faille critique WordPress : pourquoi la mise à jour automatique a échoué et comment sécuriser les sites vulnérables
La publication, le 17 juillet 2026, des correctifs d’urgence contre wp2shell a marqué un tournant dans la gestion des risques pour les administrateurs de sites. Cette faille critique combine deux défauts du cœur du CMS, permettant à un visiteur anonyme d’exécuter du code à distance sans identifiant. Si la mise à jour automatique a été activée, l’objectif de sécuriser les installations n’est pas atteint partout. Des sites restent exposés, notamment ceux où l’auto-update est désactivé. Comprendre ce qui a pu échouer est indispensable pour une remédiation efficace.
La chaîne wp2shell, une menace en deux temps pour WordPress
wp2shell n’est pas une vulnérabilité unique, mais le chaînage de deux erreurs présentes dans le cœur du CMS. La première, référencée CVE-2026-63030, touche l’endpoint /wp-json/batch/v1 de l’API REST. Cette route traite plusieurs sous-requêtes en un seul appel. Une erreur sur l’une d’elles décale les tableaux de suivi, conduisant à une confusion de routes. La requête est alors traitée par le gestionnaire d’une autre.
La seconde, CVE-2026-60137, est une injection SQL dans le paramètre author__not_in de la classe WP_Query. Le contrôle attend un tableau. En transmettant une chaîne de caractères, la vérification est contournée et la valeur brute atteint la requête SQL. Prises indépendamment, ces failles restent limitées. Chaînées, elles autorisent une prise de contrôle totale du serveur, sans cyberattaque complexe ni besoin d’un compte.
Qui a découvert cette vulnérabilité critique ?
La découverte est attribuée à Adam Kues, chercheur au sein du groupe Assetnote de Searchlight Cyber. Le signalement a été effectué via le programme HackerOne de WordPress. Trois autres chercheurs ont également rapporté l’injection SQL en parallèle, confirmant la gravité de la situation. La branche 7.1, actuellement en bêta 2, embarque déjà les deux correctifs.
Quelles versions de WordPress sont exposées et quels sont les correctifs ?
Les deux défauts ne couvrent pas les mêmes branches. L’injection SQL existe depuis WordPress 6.8, tandis que la confusion de routes n’a été introduite qu’avec la version 6.9, publiée le 2 décembre 2025. Pour évaluer correctement l’exposition, le tableau suivant détaille les versions concernées et les mises à jour disponibles.
| Version installée | Exposition | Version corrigée |
|---|---|---|
| 6.9.0 à 6.9.4 | Chaîne RCE complète, sans authentification | 6.9.5 |
| 7.0.0 à 7.0.1 | Chaîne RCE complète, sans authentification | 7.0.2 |
| 6.8.0 à 6.8.5 | Injection SQL uniquement, pas de chaîne RCE | 6.8.6 |
| Antérieures à 6.8 | Non concernées par cette chaîne | Sans objet |
Un site sur la branche 6.8 n’est donc pas exploitable en exécution de code par cette voie. Il reste cependant vulnérable à l’injection SQL, ce qui suffit à justifier une mise à jour immédiate. Il est essentiel de vérifier le numéro de version réellement installé depuis le tableau de bord d’administration, plutôt que de supposer que le correctif a été appliqué.
Pourquoi la mise à jour automatique n’a pas suffi à sécuriser les sites vulnérables
WordPress a activé les mises à jour de sécurité automatiques forcées sur les branches supportées. Cette mesure, rare, ne dispense pas d’un contrôle manuel. L’organisation n’a pas précisé si ce push forcé atteint les installations où les mises à jour automatiques ont été désactivées. Cette situation est courante sur les environnements gérés par une agence ou les configurations sur mesure.
Un autre point technique modifie la surface d’attaque. Selon l’analyse de Cloudflare, le chemin menant à l’exécution de code n’est atteignable que si aucun cache objet persistant n’est actif. Une installation par défaut n’en possède pas, donc l’exposition reste maximale sur la majorité des sites. Les administrateurs doivent donc considérer que leur site WordPress est concerné tant qu’ils n’ont pas confirmé l’application du patch de sécurité.
Les raisons courantes d’un échec de mise à jour
Plusieurs facteurs expliquent que la mise à jour automatique n’aboutisse pas. Un contrôle insuffisant des permissions sur les fichiers empêche l’écriture des nouveaux fichiers. Une configuration serveur particulière ou un hébergement ancien bloquent le processus. Le mécanisme peut aussi être volontairement désactivé pour éviter des conflits avec des extensions critiques.
Pour une gestion des mises à jour efficace, l’administrateur doit vérifier la version appliquée, mais aussi inspecter l’intégrité des fichiers. Activer WP_DEBUG_LOG aide à détecter les erreurs SQL ou les requêtes anormales. Contrôler les dates de modification dans /wp-content/ à la recherche de fichiers PHP créés ou modifiés récemment est une étape recommandée.
Ce qu’il faut vérifier immédiatement sur les sites concernés
Des exploits publics circulent depuis plusieurs jours. Des acteurs comme NetSPI et watchTowr signalent des tentatives d’exploitation réelles, à raison de centaines de fois. Ces attaques ne nécessitent qu’un simple visiteur, sans compte ni mot de passe. Voici les actions prioritaires à mener pour réduire les risques :
- Réaliser une sauvegarde complète avant toute intervention.
- Mettre à jour vers 6.8.6, 6.9.5 ou 7.0.2 selon la branche installée, puis vérifier la version effectivement affichée.
- Bloquer, via le pare-feu applicatif ou le reverse proxy, le chemin
/wp-json/batch/v1et sa forme paramétrée?rest_route=/batch/v1. Filtrer un seul des deux laisse la porte ouverte. - Restreindre l’accès non authentifié à l’API REST. Cette mesure peut casser des intégrations légitimes, elle doit être traitée comme une solution provisoire.
- Examiner les comptes administrateurs et les mots de passe d’application pour détecter toute compromission éventuelle.
Un pare-feu applicatif correctement réglé ne suffit pas dans ce cas précis. La chaîne d’attaque étant exécutée via l’API REST, le filtrage doit être appliqué au niveau du serveur pour les deux formes du chemin. Les équipes techniques doivent également surveiller les journaux pour détecter des requêtes malveillantes avant l’application du correctif.
La compromission silencieuse, une menace plus large que le piratage visible
Pour les sites non patchés, le risque dépasse le simple piratage de la page d’accueil. Un intrus peut créer des comptes administrateurs, modifier le contenu, voler des données ou installer des portes dérobées. Les recherches dans les fichiers doivent se concentrer sur les répertoires d’extensions, souvent utilisés pour dissimuler du code malveillant.
La branche 6.9 et la version 7.0 sont les plus exposées, mais la branche 6.8 reste vulnérable à l’injection SQL. Seules les installations antérieures à 6.8 ne sont pas concernées par cette chaîne. Une inspection approfondie de /wp-content/ et un contrôle des dates de modification s’imposent pour tout site ayant tourné sur une version vulnérable.
Le rôle des modèles d’IA dans la découverte de failles
L’origine de cette découverte retient l’attention. Selon Cybersecuritynews, Adam Kues aurait identifié l’injection SQL initiale à l’aide d’un modèle d’IA, avant de lui demander s’il était possible de remonter jusqu’à l’exécution de code. Le coût de calcul total de cette découverte est estimé à environ 25 dollars. Des précédents existent : un modèle d’OpenAI a repéré une faille critique passée inaperçue. Si cette tendance se confirme, le rythme de découverte dans les briques open source les plus déployées va s’accélérer.
Notre verdict sur cette faille critique WordPress
Le risque réel est plus étroit que ne le suggère le chiffre de plus de 500 millions de sites utilisant WordPress, puisque seules les branches 6.9 et 7.0 subissent la chaîne RCE complète. Pour ces installations, la mise à jour forcée ne clôt pas le sujet : tant que le numéro de version installé n’a pas été vérifié et que /wp-content/ n’a pas été inspecté, il est impossible de savoir si le site est protégé ou déjà compromis.
Le contexte actuel impose une remédiation efficace et rapide. L’absence de correctif expose directement à des tentatives d’exploitation automatisées. La vérification manuelle et la surveillance des journaux restent les seules garanties fiables. Aucun site ne devrait considérer sa sécurité comme acquise tant que ces contrôles n’ont pas été effectués. Le rythme des découvertes de vulnérabilités ne va pas ralentir, seules les méthodes de protection évoluent.
