Faille critique dans WordPress Core — RCE pré-authentifié via l'API REST (wp2shell)

Introduction

WordPress Core, qui propulse 41,9 % de tous les sites web dans le monde, est affecté par une vulnérabilité critique (CVE-2026-63030, surnommée wp2shell) permettant à un attaquant non authentifié d'exécuter du code arbitraire à distance (RCE) sur un site WordPress par défaut, sans plugin, sans compte et sans configuration particulière.

Découverte par Adam Kues, chercheur de l'équipe Assetnote de Searchlight Cyber, et signalée de manière responsable via le programme HackerOne de WordPress, la faille met en péril un parc estimé à plus de 500 millions de sites (« It is estimated that over 500 million websites use WordPress », avis officiel de Searchlight Cyber du 17 juillet 2026). WordPress a publié les correctifs le 17 juillet 2026 et a pris la mesure exceptionnelle de forcer les mises à jour automatiques sur les instances affectées — signe de la gravité de la situation.

Aucune exploitation « in the wild » n'a été confirmée à la date du 18 juillet 2026 (Rapid7, avis du 17 juillet : « No public PoC or confirmed in-the-wild exploitation was known at time of publication, though Rapid7 considers a public PoC likely to emerge soon given WordPress's open-source nature »), mais l'exposition d'un code source ouvert impose une réaction immédiate des administrateurs.

Détails de la vulnérabilité (CVE-2026-63030)

wp2shell n'est pas une faille unique mais une chaîne de deux vulnérabilités dont la combinaison fait toute la dangerosité :

• CVE-2026-63030 : une confusion de routage (route confusion, CWE-436 — interpretation conflict) dans le point de terminaison batch de l'API REST (/wp-json/batch/v1), présent dans le cœur de WordPress depuis la version 5.6, sortie en novembre 2020 (« WordPress has shipped it since 5.6 in November 2020 and documented the request format publicly ever since », The Hacker News). Score de base CVSS 7,5 (Élevé).

• CVE-2026-60137 : une injection SQL dans le paramètre author__not_in de la classe WP_Query, qui construit la quasi-totalité des requêtes base de données de WordPress. Classée CWE-89, avec un score CVSS 9,1 (Critique) attribué par le CNA WPScan (vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Description MITRE : « WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could allow SQL Injection. » Elle remonte jusqu'à WordPress 6.8.

Le mécanisme technique repose sur un désalignement d'index. L'API batch permet de regrouper plusieurs requêtes REST en un seul appel. Le cœur maintient trois listes parallèles ($requests, $validation, $matches) censées rester alignées. Lorsqu'une sous-requête échoue tôt (par exemple un chemin impossible à interpréter comme une URL), l'erreur est bien enregistrée dans $validation mais pas dans $matches. À partir de ce point, $matches est décalé d'un cran par rapport aux autres listes, et chaque sous-requête suivante est traitée avec la route, le handler et le callback de permission de la sous-requête suivante.

La chaîne d'attaque observée se déroule ainsi :

1. Envoi d'une requête batch non authentifiée en POST vers /?rest_route=/batch/v1 avec "validation":"normal" et un tableau de sous-requêtes.

2. Déclenchement du désalignement : la première sous-requête est volontairement malformée (par exemple un chemin http://:) pour renvoyer une WP_Error avant matching, sans jamais atteindre $matches.

3. Décalage des permissions : chaque sous-requête suivante est désormais évaluée contre le callback de permission d'un autre handler.

4. Contournement d'autorisation : l'attaquant ordonne les sous-requêtes de sorte qu'un handler privilégié soit validé par un contrôle de permission qu'il aurait normalement dû échouer, orientant l'exécution vers un sink accessible (l'injection SQL de CVE-2026-60137).

5. Escalade vers l'exécution de code : routée via le point batch, l'injection SQL bascule en exécution de code à distance.

Exploitation et Impact

L'attaque ne requiert aucune précondition : ni authentification, ni plugin, ni permaliens (l'endpoint répond aussi sur /?rest_route=/batch/v1). Une simple requête HTTP anonyme suffit.

Une fois l'exploitation réussie, l'attaquant obtient une exécution de code non authentifiée sur le serveur web, soit :

• La prise de contrôle totale du site et de son contenu.

• L'accès à la base de données et aux identifiants ou données personnelles qu'elle contient.

• L'exfiltration de données et l'injection de contenu ou de JavaScript malveillant.

• L'installation de portes dérobées (backdoors) et de web shells persistants.

• Le mouvement latéral dans l'environnement d'hébergement — sur les hébergements mutualisés, une seule instance compromise dépasse rarement le périmètre initial.

À noter : à la date du 18 juillet 2026, aucun PoC complet et fonctionnel de la chaîne RCE non authentifiée n'est public. Searchlight Cyber a délibérément retenu l'étape finale de l'injection SQL vers l'exécution de code, et Beazley Security comme Rapid7 confirment qu'aucun PoC exploitable n'était disponible. Des dépôts GitHub existent mais ne couvrent que la détection de l'injection ou une étape post-authentification.

Correctifs et Remédiation

L'éditeur a publié des correctifs urgents le 17 juillet 2026, disponibles pour chaque branche maintenue. Il est impératif de mettre à jour immédiatement toutes les instances exposées.

Vérifiez votre version actuelle (via WP-CLI, depuis la racine WordPress) :

# Affiche la version de WordPress installée
wp core version

Versions corrigées à déployer selon votre branche :

• WordPress 7.0.x (7.0.0 → 7.0.1) → passer à la 7.0.2

• WordPress 6.9.x (6.9.0 → 6.9.4) → passer à la 6.9.5

• WordPress 6.8.x → passer à la 6.8.6 (affectée uniquement par l'injection SQL CVE-2026-60137)

• Les versions antérieures à 6.8 ne sont pas concernées par l'injection SQL, et celles antérieures à 6.9 échappent à la chaîne RCE.

WordPress a activé la mise à jour automatique forcée, mais il faut vérifier manuellement la version réellement installée : les mises à jour automatiques peuvent échouer silencieusement (permissions de fichiers, espace disque) et n'atteignent pas les sites où elles sont désactivées.

Mesures d'atténuation temporaires si le patch ne peut être appliqué immédiatement :

• Bloquer au niveau du WAF à la fois /wp-json/batch/v1 et ?rest_route=/batch/v1 (ne bloquer qu'une seule forme laisse la seconde route ouverte).

• Désactiver l'accès anonyme à l'API REST (plugin dédié).

• Déployer une extension must-use rejetant les requêtes batch anonymes au niveau du rest_pre_dispatch.

Ces mesures peuvent perturber les intégrations REST légitimes et ne remplacent pas le correctif. Cloudflare a déployé des règles WAF pour tous ses clients dont le trafic est proxifié (« Cloudflare simultaneously released Web Application Firewall (WAF) protections for sites behind its service », Beazley Security), avant même la divulgation publique. Wordfence a publié une règle de pare-feu le 17 juillet 2026 (« Wordfence Premium, Wordfence Care, and Wordfence Response customers received a firewall rule protecting against attacks targeting the remote code execution vulnerability on July 17, 2026 »).

Détection et Indicateurs de compromission (IoC)

Aucun IoC spécifique (nom de fichier, IP) n'a été publié dans la divulgation initiale — n'inventez pas de liste de blocage. Pour détecter, concentrez-vous sur l'analyse comportementale :

• Analyse des logs : recherchez une activité inhabituelle sur l'API REST, en particulier des requêtes POST vers l'endpoint batch (/wp-json/batch/v1 ou ?rest_route=/batch/v1). Le trafic d'exploitation ressemble à du trafic REST légitime — corps JSON bien formé, sans métacaractères shell ni traversée de chemin — ce qui rend la détection par signature difficile.

• Pentests ou scans non destructif : une sonde batch envoyant une première sous-requête malformée, un DELETE sur /wp/v2/categories/0 et un POST sur le block-renderer révèle la faille de façon déterministe — un serveur vulnérable renvoie l'erreur block_cannot_read sur la sous-requête categories, un serveur patché renvoie rest_term_invalid.

• Investigation post-compromission : conservez les logs web, WAF et d'authentification avant tout nettoyage. Comparez les comptes administrateurs et application passwords à un inventaire approuvé, examinez les fichiers du cœur, thèmes, plugins et mu-plugins récemment modifiés, les tâches planifiées, les fichiers PHP inattendus dans les répertoires inscriptibles, ainsi que les redirections ou modifications de wp-config.php.

• Une mise à jour du cœur ferme la route vulnérable mais ne supprime pas une porte dérobée déjà installée : en cas de doute, restaurez à partir d'une sauvegarde saine, faites tourner les identifiants et les salts WordPress, et révoquez les sessions.

L'approche Safercy

Cette faille rappelle la criticité des surfaces d'exposition web et la vitesse à laquelle un correctif open source peut être rétro-conçu en exploit fonctionnel. Chez Safercy, notre plateforme SaferScan (Pentest-as-a-Service) intègre d'ores et déjà les vérifications nécessaires pour cette CVE, y compris la sonde de détection non destructive de l'endpoint batch.

Nos équipes Red Team, SaferSOC et réponse à incident sont mobilisées pour accompagner nos clients dans la détection d'exploits zero-day et la validation de l'étanchéité de leurs architectures web.

Une question sur votre exposition à cette CVE ou besoin d'assistance dans vos investigations ? Nos experts en réponse à incident se tiennent à votre disposition. Contactez-nous en cas de suspicion de compromission.