20 juillet 2026 CVE .

Vulnérabilités critiques wp2shell dans WordPress – Analyse et solutions

TL; DR : une exécution de code à distance sans authentification sur une installation par défaut. Un correctif publié un vendredi en fin de journée, des preuves de concept publiées dans la nuit, un avis KEV de la CISA toujours absent : anatomie d’une fenêtre d’exposition d’au moins 3 jours.

Le 17 juillet 2026, WordPress publiait en urgence trois versions correctives et déclenchait des mises à jour forcées mondiales. La faille, baptisée wp2shell, permet à un attaquant anonyme d’atteindre l’exécution de code sur une installation par défaut en combinant une vulnérabilité de confusion de route de l'API REST (CVE-2026-63030) avec une injection SQL (CVE-2026-60137).

À FAIRE IMMÉDIATEMENT

Si vous utilisez WordPress, vérifiez que la version installée est bien 7.0.2, 6.9.5 ou 6.8.6 (ou ultérieure). Ne présumez pas que la mise à jour forcée a fonctionné et contrôlez la version sur chaque instance, sur tous vos WordPress.

CE QU’IL FAUT RETENIR

La faille : wp2shell combine deux vulnérabilités au cœur de WordPress (CVE-2026-63030 et CVE-2026-60137) pour atteindre une exécution de code sans authentification (RCE pre-auth), sans extension tierce ni interaction utilisateur.
Versions concernées :
- Versions vulnérables 6.9.0–6.9.4 et 7.0.0–7.0.1
- Correctifs : 7.0.2, 6.9.5, 6.8.6 (depuis le 17 juillet 2026)
Date de publication : très mal choisie, les développeurs de WordPress ont décidé de publier un correctif critique un vendredi après-midi aux USA, correspondant au soir en Europe, sachant que le correctif serait analysé pour construire une charge utile malveillante (exploit), mettant en difficulté toutes les équipes sécurité un week-end.
Les mises à jour forcées ne suffisent pas : elles n’atteignent pas les installations les ayant désactivées ou bloquées. Vérifiez la version réellement en place.
Délai d’exposition : plusieurs jours entre la publication du correctif et l’avis de la CISA alors que des preuves de concept publiques circulaient dès la nuit de vendredi à samedi.
Corriger ne suffit pas : du fait de la mise à disposition rapide d'un code d'exploitation, il est impérative de rechercher des indicateurs de compromission sur la fenêtre d'exposition concernée.
La vulnérabilité wp2shell (CVE-2026-63030) a été découverte par un chercheur utilisant un prompt fournit par OpenAI et modifié, combiné au modèle GPT-5.6 Sol assisté d’agents IA, qui ont analysé le code de WordPress pour identifier la vulnérabilié et construire l’exploit.

Chronologie de la divulgation de wp2shell

Quand	Quoi	Source
Ven. 17 · 18h00	WordPress publie les versions 7.0.2, 6.9.5 et 6.8.6 et active les mises à jour forcées.	wordpress.org
Ven. 17	Publication des bulletins d'alerte GitHub GHSA-ff9f-jf42-662q et GHSA-fpp7-x2x2-2mjf.	GHSA-ff9f · GHSA-fpp7
Ven. 17 · 19h03	Cloudflare active deux règles WAF (17h03 UTC).	blog.cloudflare.com
Ven. 17 · 20h53	WordPress relaie le correctif sur ses canaux de communication.	Canaux officiels WordPress
Sam. 18 · ~01h00	Premiers signaux d'exploitation et apparition d'une preuve de concept publique.	Non référencé volontairement
Sam. 18 10h (GMT+2)	Intégration dans Patrowl et scan de tous les clients.	—
Sam. 18	Analyses divergentes des éditeurs de sécurité sur le statut d'exploitation.	—
Lun. 20 · 10h20	Publication de l'avis du CERT-FR.	cert.ssi.gouv.fr
Mardi 21	CVE-2026-63030 n'apparaît pas au catalogue KEV de la CISA.	cisa.gov

Comment fonctionne la chaîne d’exploitation wp2shell

Le nom évoque un défaut unique. La réalité est tout autre : deux faiblesses indépendantes qui, combinées, produisent l’exécution de code.

Confusion de route (CVE-2026-63030)

WordPress 6.9 introduit un chemin d'accès dans son API REST (/wp-json/batch/v1 ou ?rest_route=/batch/v1) permettant d'envoyer plusieurs requêtes dans un même appel API, afin d'optimiser les performances. La vulnérabilité CVE-2026-63030 est une confusion de route sur cet chemin, permettant de contourner le contrôle de l'autorisation.

Injection SQL (CVE-2026-60137)

La vulnérabilité CVE-2026-60137 est une injection SQL (SQLi) authentifiée dans le paramètre authornotin de WP_Query.

Chaînage des vulnérabilités

La confusion de route contourne le contrôle des autorisation, permettant d'exploiter l’injection SQL sans authentification. Depuis l'injection SQL il est possible d'extraire des données de la base, comme le condensat du mot de passe de l'admin pour tenter de le casser hors-ligne, puis prendre le contrôle du WordPress en déposant, par exemple une porte dérobée comme un webshell.

CONDITION D’EXPLOITABILITÉ SOUVENT OMISE

Cloudflare indique que le chemin vulnérable de CVE-2026-63030 est atteignable lorsqu’un cache objet persistant n’est pas utilisé. Un site avec Redis ou Memcached peut ne pas présenter le même chemin, mais l’injection SQL reste à corriger.

Le désaccord sur l’évaluation de la sévérité

Sans surprise et comme nous le répétons, un pilotage uniquement par le score CVSS et les listes telles que la KEV de la CISA est insuffisant. Il est nécessaire de combiner les scores des vulnérabilités et de les analyser par rapport à leur exploitation dans la nature et leur impact réel.

Versions de WordPress affectées par wp2shell

Branche	Versions affectées	Exposition	Version corrigée
7.0	7.0.0 à 7.0.1	Chaîne wp2shell complète	7.0.2
6.9	6.9.0 à 6.9.4	Chaîne wp2shell complète	6.9.5
6.8	6.8.0 à 6.8.5	Injection SQL uniquement	6.8.6
7.1 bêta	Versions bêta	Correctif intégré	7.1 Bêta 2
Antérieures à 6.8	Non affectées	—	—

WordPress est utilisé par plus de 40% des sites web. Une faille non authentifiée dans le cœur de ce CMS transforme instantanément tous ces sites en cibles automatisables (wormable).

L’ANGLE MORT LE PLUS FRÉQUENT

En plus des sites principaux, un risque important est présent vis à vis des sites oubliés : préproductions, sites de campagne temporaire, blogs de filiales, sous-domaines hérités, environnements de recette laissés en ligne....

Chez Patrowl,deux contrôles plutôt qu'un seul

Notre priorité chez Patrowl a été d'alerter nos clients au plus vite, chaque minute comptait. De ce fait, nous avons fait le choix de réaliser un premier contrôle analysant finement les versions réelles des WordPress, laissant quelques précieuses minutes pour intégrer un code d'exploitation complet permettant de confirmer la présence des vulnérabilités.

Ce premier contrôle, déjà partiellement présent, permettait de détecter les versions de WordPress avec notre EASM, plus fin que les classiques balises <meta name="generator"> et fichiers /readme.html.

Le second contrôle, intégré quelques minutes après, chaînait les deux vulnérabilités afin de confirmer la vulnérabilité réelle des actifs.

Comment corriger wp2shell : mise à jour et contournements

1. Vérifier la version réellement installée

Les mises à jour forcées n’atteignent pas toutes les installations. Contrôlez la version sur chaque instance.

Méthodes pour vérifier la version :

Depuis le tableau de bord WordPress : rubrique Mises à jour.

Via le code source de la page (si non masqué) :
- Faire un clic droit → « Afficher le code source »
- Chercher la balise <meta name="generator" content="WordPress X.X.X" />
  Mais cette balise est souvent supprimée ou falsifiée sur les sites durcis.

En ligne de commande :

wp core version --path=/var/www/monsite

En lisant le fichier wp-includes/version.php

Une instance est à jour si elle affiche 7.0.2, 6.9.5, 6.8.6 ou ultérieur.

2. Si le correctif ne peut pas être appliqué immédiatement

Des contournements temporaires existent pour bloquer l’accès non authentifié à l'injection SQL.

ERREUR CLASSIQUE À ÉVITER

Ne filtrez pas uniquement /wp-json. L’endpoint est aussi atteignable via ?rest_route=/batch/v1.

Exemple Apache :

text
<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{REQUEST_URI} ^/wp-json/batch/v1/?$ [NC,OR]RewriteCond %{QUERY_STRING} (^|&)rest_route=/batch/v1/?(&|$) [NC]RewriteRule ^ - [F,L]</IfModule>

Cloudflare a déployé deux règles WAF le 17 juillet à 17h03 UTC. Vérifiez qu’elles sont activées et que vos surcharges ne les neutralisent pas.

UN AVIS DIVERGENT

Certains recommandent de ne pas s’appuyer sur des contournements. Cloudflare les présente comme une réduction d’exposition temporaire. Les deux convergent : un contournement achète du temps, il ne règle rien.

3. Ne pas confondre version affectée et exposition réelle

Un actif affichant une version vulnérable n’est pas nécessairement exploitable : WAF, cache objet persistant, endpoint restreint ou correctif rétroporté peuvent réduire le risque.

Vérifier si votre site WordPress a été compromis

Appliquer le correctif ferme la porte, mais ne dit rien de la période antérieure. Si les gens n’ont pas mis à jour samedi ou dimanche, il y a de fortes chances qu’un invité surprise soit dans leur WordPress.

Commencez par :

Comptes administrateurs : rechercher les créations récentes de compte ou élévations de privilèges non justifiées.
Extensions et fichiers : rechercher les extensions inconnue et fichiers PHP dans un répertoire d’upload
Base de données : recherche des entrées anormales dans wp_posts ou wp_options.
Journaux du serveur web : analyser les requêtes vers le chemin d'API vulnérable
Changer le mot de passe administrateur : ce n'est pas nécéssaire si le site n'a pas été compromis, mais c'est une bonne pratique d'hygiène sécurité

# Recherche des requêtes vers l’endpoint batch
grep -E"batch/v1" /var/log/nginx/access.log*
# Fichiers PHP récemment créés dans uploads
find /var/www/monsite/wp-content/uploads -name"*.php" -mtime -7 -ls
# Comptes administrateurs
wp user list --role=administrator --fields=ID,user_login,user_registered

SI VOUS TROUVEZ QUELQUE CHOSE

Une compromission avérée impose de traiter le mot de passe administrateur comme ayant fuité :

Renouvelez les identifiants,
invalidez les sessions,
changez les clés de salage.

Si un webshell a pu être déposé, privilégiez une réinstallation à partir d’une source saine.

Si vous disposez de sauvegardes récentes, une restauration complète peut être envisagée.

Ce que wp2shell révèle de vos processus de remédiation

Au-delà du cas WordPress, cet épisode constitue un test grandeur nature de votre processus de gestion des vulnérabilités. La question n’est pas « avez-vous corrigé », mais « qu’est-ce qui aurait déclenché votre procédure d’urgence, et quand ».

Si votre escalade repose sur l’inscription au catalogue KEV de la CISA ou sur la publication d’un avis du CERT-FR, vous avez traversé tout un week-end sans signal, alors que le correctif, le bulletin d’alerte du mainteneur et une preuve de concept publique existaient. Ces référentiels sont légitimes et précieux, mais ils reposent par construction sur une consolidation de preuves qui prend du temps. Les concevoir comme déclencheur unique revient à indexer votre réactivité sur le maillon le plus lent de la chaîne.

Si votre escalade repose sur le score CVSS, vous avez pu déclasser en sévérité haute une faille que le mainteneur qualifiait de critique, en raison d’une divergence de notation entre organismes sur la même vulnérabilité.

Si elle repose sur votre scanner de vulnérabilités, la question devient celle du délai d’intégration de la signature, puis de la fréquence de vos scans. Un scan hebdomadaire aurait pu vous donner un signal mais trop tard. Un scan mensuel ne vous aurait pas aidé.

LE DÉCLENCHEUR LE PLUS PRÉCOCE

L’information la plus rapide et la mieux qualifiée était le bulletin d’alerte GitHub, disponible le jour même, avec la mention « critique », les versions affectées et la version corrigée.

Wp2shell : ce qu’il faut retenir

Wp2shell restera un cas d’école, moins par sa sophistication technique que par sa chronologie. L’éditeur a réagi vite et fort, peut-être trop vite.

Et pourtant, une organisation attendant un signal officiel a traversé un week-end entier sans savoir qu’une exécution de code non authentifiée était corrigée et exploitée dans la nature.

La leçon : Il faut être capable de surveiller les bulletins d’alerte des éditeurs, les canaux github, twitter, les blogs... mais également maintenir un inventaire à jour et savoir vérifier une version sur l’ensemble d’un parc en quelques minutes afin de transformer ces 3 jours d’attente en une soirée de travail.

FAQ

Mon site est-il vulnérable ?

Si vous exécutez WordPress 6.9.0 à 6.9.4 ou 7.0.0 à 7.0.1, vous êtes exposé à la chaîne complète. En 6.8.0 à 6.8.5, vous êtes concerné par l'injection SQL uniquement. Les versions 6.9.5, 7.0.2, 6.8.6 ou ultérieures sont corrigées.

Les mises à jour forcées ne m'ont-elles pas déjà protégé ?

Probablement, mais pas certainement. Le mécanisme n'atteint pas les installations l'ayant désactivé ou bloqué. Vérifiez la version sur chaque instance.

Une extension tierce est-elle nécessaire pour être exposé ?

Non. Une installation par défaut, sans extension, sans configuration particulière et sans compte valide, est atteignable.

La faille est-elle exploitée dans la nature ?

Des preuves de concept publiques circulent, ce qui justifie un traitement en urgence indépendamment du statut d'exploitation confirmé.

Le cache objet persistant me protège-t-il ?

Cloudflare indique que le chemin vulnérable de CVE-2026-63030 est atteignable lorsqu'un cache objet persistant n'est pas utilisé. Cela reste un facteur de priorisation, pas une dispense.

Bloquer l'endpoint au WAF suffit-il ?

Non. Mesure d'attente, pas un correctif. Elle doit couvrir les deux chemins d'accès et peut perturber des intégrations légitimes.

Pourquoi les évaluations de sévérité diffèrent-elles selon les sources ?

Parce que plusieurs organismes peuvent évaluer indépendamment la même vulnérabilité, avec des hypothèses différentes sur le vecteur et l'impact. En cas de doute, retenez la criticité la plus élevée.

J'ai appliqué le correctif, dois-je aller plus loin ?

Oui. Un correctif appliqué aujourd'hui ne renseigne pas sur la période antérieure. Recherchez les comptes administrateurs créés récemment, les extensions et fichiers PHP inconnus, les entrées anormales en base et les requêtes vers l'endpoint batch.

Que faire si je découvre une compromission ?

Considérez le mot de passe administrateur comme divulgué. Renouvelez les identifiants, invalidez les sessions, changez les clés de salage. Si un webshell a pu être déposé, une réinstallation à partir d'une source saine est préférable à un nettoyage.

Comment être alerté plus tôt la prochaine fois ?

En ne faisant pas dépendre votre déclencheur des seuls référentiels consolidés. Les bulletins d'alerte des mainteneurs sont disponibles plus tôt. Encore faut-il disposer d'un inventaire à jour des produits que vous exposez.