L’essentiel en bref
- wp2shell combine deux failles du cœur de WordPress : CVE-2026-63030 (confusion de routes dans l’API REST) et CVE-2026-60137 (injection SQL dans WP_Query).
- La chaîne complète d’exécution de code touche les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Les correctifs sont 6.9.5, 7.0.2 et 6.8.6.
- Aucun plugin, aucun réglage particulier et aucun identifiant ne sont nécessaires à l’attaquant, selon Searchlight Cyber.
- WordPress a activé les mises à jour automatiques forcées, mais elles ne couvrent pas les installations où l’auto-update est désactivé.
Accès rapide (Sommaire) :
Ce que fait exactement la chaîne wp2shell (à l’origine de la faille WordPress de la décennie)
wp2shell n’est pas une faille unique, c’est l’assemblage de deux erreurs distinctes dans le cœur du CMS et une faille critique du coeur même de WordPress.
La première, CVE-2026-63030, touche l’endpoint /wp-json/batch/v1 de l’API REST. Cette route exécute plusieurs sous-requêtes en un seul appel. Une erreur sur l’une d’elles décale les tableaux de suivi d’un cran.
Résultat : une requête est traitée par le gestionnaire d’une autre requête.
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 lui passant une chaîne de caractères, la vérification est contournée et la valeur brute atteint la requête SQL.
Prises séparément, ces deux failles restent limitées mais chaînées, elles donnent un accès complet au serveur à un visiteur anonyme.
La découverte revient à Adam Kues, du groupe Assetnote de Searchlight Cyber, qui a signalé la faille via le programme HackerOne de WordPress. L’injection SQL a été rapportée en parallèle par trois autres chercheurs.
Quelles versions de WordPress sont réellement exposées ?
Les deux failles ne couvrent pas les mêmes branches :
- L’injection SQL existe depuis WordPress 6.8.
- La confusion de routes, elle, n’a été introduite qu’avec la version 6.9, sortie le 2 décembre 2025.
La branche 7.1 en bêta 2 embarque les deux correctifs.
Un site sur 6.8 n’est donc pas exploitable en exécution de code par cette voie mais il reste vulnérable à l’injection SQL, ce qui suffit à justifier la mise à jour.
Une précision technique change aussi 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 a pas, donc l’exposition reste maximale sur la majorité des sites.
Pourquoi ce cas sort de l’ordinaire pour les équipes web ?
Les failles WordPress dont nous parlons habituellement viennent des extensions.
C’était le cas avec la brèche repérée dans Slider Revolution ou avec le plugin Post SMTP par exemple.
Ici, le problème est dans le cœur du CMS, mais aucun audit de plugins ne vous met à l’abri. Searchlight Cyber estime que plus de 500 millions de sites tournent sous WordPress.
La chaîne RCE ne concerne que les installations passées en 6.9 ou 7.0, soit des versions de moins de huit mois.
Deuxième particularité : WordPress a activé les mises à jour de sécurité automatiques forcées sur les branches supportées. La mesure est rare mais elle ne dispense pas de vérifier.
WordPress n’a pas indiqué si le push forcé atteint les sites où les mises à jour automatiques ont été coupées, ce qui est courant sur les environnements gérés par une agence.
Allez lire le numéro de version réellement installé depuis le tableau de bord d’administration plutôt que de supposer.
Ce qu’il faut faire aujourd’hui, dans l’ordre :
Des exploits publics circulent depuis quelques jours, plusieurs acteurs, dont NetSPI et watchTowr, signalent des tentatives d’exploitation réelles. Voici ce que vous devez absolument vérifier dès maintenant :
- Réalisez un backup de votre site avant toute intervention.
- Mettez à jour vers 6.8.6, 6.9.5 ou 7.0.2 selon votre branche, puis vérifiez la version après application.
- Si la mise à jour n’est pas possible tout de suite, bloquez au niveau du WAF ou du reverse proxy le chemin /wp-json/batch/v1 et sa forme en paramètre ?rest_route=/batch/v1. Filtrer un seul des deux laisse la porte ouverte.
- À défaut, restreignez l’accès non authentifié à l’API REST. Cette mesure peut casser des intégrations légitimes, donc traitez-la comme un pansement.
- Activez WP_DEBUG_LOG et cherchez les erreurs SQL ou les requêtes anormales sur la période récente.
- Contrôlez les dates de modification dans /wp-content/ à la recherche de fichiers PHP créés ou modifiés récemment.
- Passez en revue les comptes administrateurs et les mots de passe d’application.
Si vous pensez être protégé par un pare-feu applicatif correctement réglé, sachez que dans ce cas précis, ce n’est pas suffisant.
Le détail qui devrait retenir l’attention des équipes techniques
Un élément du dossier dépasse le cadre WordPress.
D’après le récit publié par Cybersecuritynews, Adam Kues aurait identifié l’injection SQL initiale à l’aide d’un modèle d’IA, avant de lui demander s’il pouvait remonter jusqu’à l’exécution de code.
Le coût de calcul total de la découverte est estimé à seulement environ 25 dollars, toujours selon ce récit.
Nous avions déjà relayé le cas d’un modèle d’OpenAI repérant une faille critique passée inaperçue et le cas Fable 5 bloqué temporairement par le gouvernement américain est aussi très parlant.
Si la tendance se confirme, le rythme de découverte de vulnérabilités dans les briques open source les plus déployées va s’accélérer.
Vos cycles de mise à jour, eux, n’ont pas changé de vitesse.
Notre verdict :
Le risque réel est plus étroit que ne le suggère le chiffre de 500 millions de sites, puisque seules les branches 6.9 et 7.0 subissent la chaîne complète. Mais pour ces sites-là, la mise à jour forcée ne suffit pas à clore le sujet : tant que vous n’avez pas lu le numéro de version installé et inspecté /wp-content/, vous ne savez pas si vous êtes patché ou déjà compromis.
Et vous, avez-vous bien vérifié tous vos sites WordPress ?
Principalement passionné par les nouvelles technologies, l’IA, la cybersécurité, je suis un professionnel de nature discrète qui n’aime pas trop les réseaux sociaux (je n’ai pas de comptes publics). Rédacteur indépendant pour LEPTIDIGITAL, j’interviens en priorité sur des sujets d’actualité mais aussi sur des articles de fond. Pour me contacter : [email protected]
