Faille WordPress WP2Shell : CVE-2026-63030 permet une RCE sans authentification

Dans le cadre de notre veille sécurité, nous signalons WP2Shell, une chaîne de vulnérabilités critiques affectant le coeur de WordPress.

La première faille, CVE-2026-63030, provoque une confusion de route dans le point d’entrée batch de l’API REST. Combinée à CVE-2026-60137, une injection SQL dans le paramètre author__not_in de WP_Query, elle peut permettre à un attaquant d’obtenir une exécution de code à distance sans authentification.

Le scénario est particulièrement sérieux : il ne nécessite ni compte valide, ni interaction d’un administrateur, ni extension vulnérable. Une installation standard de WordPress dans une version affectée peut suffire. Des preuves de concept publiques étant désormais signalées, la vérification des versions et la mise à jour doivent être traitées immédiatement.

Faille WordPress WP2Shell : deux vulnérabilités chaînées

WP2Shell ne désigne pas une faille isolée, mais l’enchaînement de deux défauts dans WordPress :

1. CVE-2026-63030 concerne le traitement des routes par le point d’entrée batch de l’API REST, introduit avec WordPress 6.9. Une confusion dans l’interprétation de la route permet d’atteindre un comportement qui ne devrait pas être accessible de cette manière.
2. CVE-2026-60137 est une injection SQL facilitée dans le paramètre author__not_in de WP_Query.

La combinaison des deux failles transforme une injection SQL en chaîne d’exploitation pouvant aller jusqu’à l’exécution de code sur le serveur. CVE-2026-63030 a reçu un score CVSS 3.1 de 9,8/10 de la part de WPScan, l’autorité ayant publié l’enregistrement. Le NVD n’avait pas encore produit sa propre évaluation au moment de la rédaction.

Cette distinction est importante pour la remédiation : corriger uniquement un symptôme au niveau du serveur web ne suffit pas. Il faut déployer les versions de WordPress qui corrigent les deux vulnérabilités concernées.

Quelles versions de WordPress sont concernées ?

La chaîne WP2Shell complète concerne les branches 6.9 et 7.0 de WordPress :

WordPress a activé des mises à jour de sécurité forcées pour les sites affectés qui prennent en charge les mises à jour automatiques en arrière-plan. Il ne faut toutefois pas supposer que l’opération a réussi : permissions de fichiers, configuration, espace disque, mécanisme de déploiement ou désactivation volontaire des mises à jour peuvent laisser un site sur une version vulnérable.

Pourquoi une exécution de code à distance change le niveau de réponse

Une exécution de code à distance ne se limite pas à la modification d’une page. Elle peut permettre à un attaquant d’agir avec les droits du processus qui exécute WordPress et, selon l’architecture, de :

• lire ou modifier les fichiers du site ;
• récupérer les accès à la base de données présents dans la configuration ;
• créer une porte dérobée persistante dans un thème, une extension ou un fichier ajouté ;
• créer ou détourner des comptes administrateurs ;
• injecter du contenu frauduleux, du phishing ou du spam ;
• accéder aux secrets disponibles dans l’environnement d’exécution ;
• utiliser le serveur comme point de rebond vers d’autres services accessibles.

Le cloisonnement de l’hébergement reste utile : un processus WordPress peu privilégié, des secrets limités, des droits de fichiers stricts et une segmentation réseau réduisent l’impact. Ils ne rendent pas la vulnérabilité acceptable. Après une exploitation plausible, la confiance dans l’application et ses secrets doit être réévaluée.

Remédiation : mettre WordPress à jour immédiatement

La remédiation prioritaire consiste à déployer une version corrigée :

• WordPress 7.0.2 ou une version ultérieure maintenue pour la branche 7.0 ;
• WordPress 6.9.5 ou une version ultérieure maintenue pour la branche 6.9 ;
• WordPress 6.8.6 ou une version ultérieure maintenue pour les sites encore sur la branche 6.8, afin de corriger CVE-2026-60137 même si la chaîne WP2Shell complète ne s’y applique pas.

La mise à jour doit suivre une procédure contrôlée :

1. inventorier tous les sites et relever leur version réelle, y compris les environnements de préproduction ou les anciennes instances encore exposées ;
2. vérifier la disponibilité d’une sauvegarde récente des fichiers et de la base de données, ainsi que la capacité à la restaurer ;
3. appliquer la mise à jour de sécurité depuis le mécanisme de déploiement habituel ou le tableau de bord WordPress ;
4. confirmer la version effectivement déployée après l’opération ;
5. purger les caches si nécessaire et tester les parcours importants : connexion, formulaires, paiement, publication et appels API ;
6. contrôler les journaux et l’intégrité du site avant de refermer l’intervention.

Une sauvegarde est une précaution avant intervention, pas un substitut au correctif. Restaurer une copie déjà vulnérable sans la mettre à jour rouvre immédiatement la même exposition.

Mitigation temporaire si le correctif doit attendre

Si une contrainte technique empêche momentanément la mise à jour, Searchlight Cyber recommande de bloquer les accès anonymes au point d’entrée batch de l’API REST. Le filtrage peut cibler les deux formes de route suivantes :

/wp-json/batch/v1
?rest_route=/batch/v1

Cette mesure peut être appliquée au niveau d’un WAF ou par un mécanisme WordPress qui interdit l’accès anonyme à l’API REST. Elle peut cependant casser des usages légitimes de l’API. Elle doit donc être testée, surveillée et retirée après l’installation du correctif.

Un filtrage de route reste une mesure compensatoire d’urgence. Il ne corrige ni le code vulnérable, ni une éventuelle compromission antérieure.

Rechercher les signes d’une compromission

La publication d’une preuve de concept ne prouve pas qu’un site donné a été attaqué. Elle augmente en revanche la probabilité de scans et de tentatives automatisées. Pour une instance restée exposée dans une version vulnérable, il faut examiner au minimum :

• les requêtes vers les routes batch de l’API REST dans les journaux du serveur web, du reverse proxy et du WAF ;
• les fichiers PHP récemment créés ou modifiés dans les thèmes, les extensions, les répertoires d’uploads et la racine du site ;
• les comptes administrateurs, sessions, mots de passe applicatifs et clés API apparus ou modifiés sans explication ;
• les tâches planifiées, extensions obligatoires, extensions classiques et thèmes installés ou réactivés récemment ;
• les connexions sortantes, processus ou consommations de ressources inhabituels ;
• les modifications du coeur de WordPress par rapport aux fichiers attendus de la version installée.

En cas d’indicateur sérieux, une simple mise à jour ne suffit plus. Il faut conserver les éléments utiles à l’analyse, isoler le site si nécessaire, repartir de sources saines, restaurer uniquement des données contrôlées et faire tourner les secrets accessibles depuis l’instance : identifiants de base de données, clés d’administration, accès d’hébergement, clés API et secrets applicatifs.

WordPress reste une cible privilégiée compte tenu de sa popularité

WordPress occupe une place majeure sur le web. Cette popularité rend rentable l’automatisation des recherches de vulnérabilités : lorsqu’une faille devient publique, un attaquant peut scanner un grand nombre de sites sans connaître leur propriétaire ni leur activité.

WP2Shell concerne le coeur de WordPress, mais le même principe s’applique à tout son écosystème. Chaque extension et chaque thème ajoutent du code tiers, donc une dépendance à inventorier et à maintenir. Une extension peut devenir une faille, être abandonnée par son éditeur ou rester installée longtemps après la fin de son usage.

La sécurité d’un site WordPress exige donc une veille continue et un suivi scrupuleux : versions du coeur, extensions, thèmes, CVE publiées, avis des mainteneurs, maintenance planifiée, sauvegardes testées et contrôle après mise à jour. Ce travail ne peut pas reposer uniquement sur une alerte occasionnelle ou sur l’espoir qu’une mise à jour automatique se déroule toujours correctement.

Nous assurons aussi l’infogérance des sites WordPress

Forget About IT assure également l’infogérance de sites WordPress. Nous les considérons comme des applications web exposées, avec des composants, des accès, des données, des dépendances et des exigences de reprise à documenter.

La prise en charge peut couvrir :

• l’inventaire du coeur, des extensions, des thèmes et des environnements exposés ;
• la veille sur les CVE et la qualification de l’exposition réelle ;
• la planification et l’application des maintenances de sécurité ;
• les sauvegardes externalisées et les tests de restauration ;
• la supervision de la disponibilité, des certificats, des erreurs et des ressources ;
• le durcissement des accès, des permissions et de l’exécution PHP ;
• le filtrage par WAF et la protection des zones sensibles ;
• la conservation des journaux et la réaction aux incidents.

L’objectif n’est pas d’empiler des extensions de sécurité. Il est d’organiser l’exploitation : savoir ce qui est déployé, détecter les vulnérabilités qui concernent réellement le site, corriger dans un délai adapté à la criticité et disposer d’une procédure fiable si un incident survient.

Ce qu’il faut retenir de CVE-2026-63030

WP2Shell rappelle qu’une vulnérabilité critique peut aussi se trouver dans le coeur de WordPress et affecter une installation standard. Dans ce cas précis, la combinaison de CVE-2026-63030 et CVE-2026-60137 permet une exécution de code à distance sans authentification sur les versions concernées.

La priorité est claire : identifier les instances WordPress 6.9.x et 7.0.x, mettre à jour sans délai, vérifier le résultat et investiguer toute exposition suspecte. Le WAF peut réduire temporairement le risque, mais il ne remplace ni le correctif ni une maintenance suivie.

• Découvrir notre offre d’infogérance
• Lire notre article sur la maintenance WordPress en 2026
• Lire pourquoi le suivi quotidien des CVE est nécessaire
• Nous contacter
• Prendre rendez-vous

Sources

• NVD - CVE-2026-63030
• Security Affairs - Attackers Can Take Over WordPress Sites Using Newly Released wp2shell Exploits
• WordPress Security Advisory - CVE-2026-63030
• WordPress Security Advisory - CVE-2026-60137
• WordPress - Version 7.0.2 security release
• Searchlight Cyber - wp2shell: Pre Authentication RCE in WordPress Core

FAQ : faille WordPress WP2Shell CVE-2026-63030

Qu’est-ce que la faille WordPress WP2Shell ?

WP2Shell désigne une chaîne d’exploitation combinant CVE-2026-63030, une confusion de route dans l’API REST, et CVE-2026-60137, une injection SQL. Elle peut mener à une exécution de code à distance sans authentification.

Quelles versions de WordPress sont vulnérables à WP2Shell ?

La chaîne complète affecte WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Les versions corrigées sont WordPress 6.9.5 et 7.0.2. WordPress 6.8 n’est pas exposé à la chaîne complète, mais doit passer en 6.8.6 pour corriger CVE-2026-60137.

Une extension vulnérable est-elle nécessaire pour exploiter WP2Shell ?

Non. Les vulnérabilités se trouvent dans le coeur de WordPress et la chaîne peut viser une installation standard sans extension, sans compte valide et sans interaction d’un utilisateur.

Comment corriger CVE-2026-63030 ?

Il faut mettre immédiatement WordPress à jour vers 7.0.2 ou vers 6.9.5 pour les sites maintenus sur la branche 6.9, puis vérifier la version réellement déployée, le bon fonctionnement du site et les journaux de sécurité.

Que faire si la mise à jour WordPress ne peut pas être appliquée immédiatement ?

Une mesure temporaire consiste à bloquer les accès anonymes aux routes /wp-json/batch/v1 et ?rest_route=/batch/v1 au niveau du WAF ou de l’application. Cette mitigation peut perturber des fonctions légitimes et ne remplace pas la mise à jour.

Forget About IT assure-t-il l’infogérance de sites WordPress ?

Oui. Forget About IT peut prendre en charge la maintenance, la veille sur les vulnérabilités, les sauvegardes, la supervision, le durcissement et la réaction aux incidents des sites WordPress.