CVE-2026-63030 wp2shell : WordPress RCE pré-auth CVSS 9.8

Les faits

Le 17 juillet 2026, WordPress a publié en urgence les versions correctives 6.9.5 et 7.0.2 pour colmater une chaîne d'exploitation critique surnommée wp2shell par la communauté sécurité. Cette chaîne combine deux vulnérabilités distinctes du cœur de WordPress — CVE-2026-63030 et CVE-2026-60137 — pour permettre à un attaquant non authentifié d'exécuter du code arbitraire sur tout serveur WordPress vulnérable, sans aucun plugin, sans configuration spéciale et sans intervention d'un utilisateur connecté. La portée potentielle est considérable : WordPress alimente plus de 40 % des sites web mondiaux, et les versions affectées 6.9.x et 7.0.x représentent une fraction importante des installations actives.

CVE-2026-63030 est une vulnérabilité logique (CWE-284, Improper Access Control) affectant le processeur de requêtes batch de l'API REST WordPress, accessible via le point d'entrée /wp-json/batch/v1. Ce endpoint, introduit pour optimiser les performances en permettant de regrouper plusieurs appels REST dans une seule requête HTTP, souffre d'une désynchronisation critique entre deux tableaux internes. Lors du traitement d'une sous-requête batch, la fonction wp_parse_url() analyse l'URL de chaque sous-requête pour déterminer le gestionnaire REST approprié. Lorsque l'analyse échoue (URL malformée), l'erreur est correctement poussée dans le tableau de validation (validation_responses), mais le tableau de correspondances (matches) n'est pas mis à jour. Cette désynchronisation entre les index des deux tableaux a pour effet que toutes les sous-requêtes suivantes dans le batch sont dispatchées vers le gestionnaire incorrect — celui de la sous-requête précédente. Le score CVSS v3.1 de CVE-2026-63030 est de 9.8 (Critique) selon le rapport NVD/NIST, reflétant l'absence totale de pré-condition d'exploitation.

CVE-2026-60137 est une injection SQL (CWE-89) présente dans le paramètre author__not_in de l'endpoint posts de l'API REST WordPress. Quand ce paramètre est fourni sous forme de chaîne scalaire (string) plutôt que sous forme de tableau (array), sa valeur est interpolée directement dans une requête SQL brute sans passer par le mécanisme de préparation wpdb::prepare. Cette faille serait de sévérité modérée prise isolément (CVSS 5.9), car elle nécessite normalement des droits d'auteur pour être exploitée. Mais utilisée en tandem avec CVE-2026-63030, elle devient l'étage terminal d'une chaîne d'exécution de code à distance pré-authentifiée redoutable.

La chaîne d'exploitation wp2shell fonctionne en deux étapes. Première étape : l'attaquant envoie une requête batch malformée via CVE-2026-63030 qui force le dispatcher REST à traiter une sous-requête sous le contexte d'autorisation d'un utilisateur inexistant ou d'un niveau privilégié inapproprié. Deuxième étape : la sous-requête en question exploite CVE-2026-60137 pour injecter du SQL arbitraire dans le moteur WordPress, permettant de lire des données de la base (dont les hashes de mots de passe administrateur) ou, dans les configurations les plus permissives, d'écrire des fichiers sur le système de fichiers via les fonctions de base de données (SELECT INTO OUTFILE). Des preuves de concept publics sont disponibles depuis le 20 juillet 2026, plusieurs démontrant la lecture complète de la base de données WordPress incluant les credentials administrateur. Des PoC avancés montrent la possibilité d'écrire un webshell PHP sur le serveur via la commande SQL lorsque les permissions DB l'autorisent — d'où le nom wp2shell.

La timeline de divulgation est particulièrement serrée. L'advisory GitHub Security Advisory a été publié le 17 juillet 2026, accompagné du patch dans les mêmes heures. Les premières tentatives d'exploitation in-the-wild ont été détectées dès le 18 juillet 2026 par Wiz et Akamai, soit moins de 24 heures après la publication du patch. Akamai a documenté une vague d'exploitation de masse débutant le 20 juillet 2026, avec des milliers de sites ciblés quotidiennement par des scanners automatisés utilisant la chaîne wp2shell. Cloudflare a mis à jour ses règles WAF dans les heures suivant la divulgation pour bloquer les payloads identifiés, mais la protection WAF seule ne remplace pas le patch en raison de la diversité des vecteurs d'encodage possibles.

Les versions affectées couvrent WordPress 6.8.0 à 6.8.5 (uniquement pour CVE-2026-60137), 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 (pour les deux CVE combinées). Les correctifs ont été publiés dans WordPress 6.9.5 et 7.0.2 le 17 juillet 2026. Selon Rapid7 et Tenable, la faille est présente dans le code de traitement batch depuis son introduction dans WordPress 7.0.0, et la vulnérabilité SQL injection est présente depuis la version 6.8.0 — soit plusieurs mois d'exposition potentielle avant découverte. Aucun contournement sans patch n'est officiellement recommandé : désactiver l'API REST via des plugins peut casser des fonctionnalités essentielles et n'est pas garanti de bloquer toutes les variantes d'exploitation.

L'exploitation massive confirmée fait de wp2shell l'une des vulnérabilités WordPress les plus critiques observées ces dernières années. Les attaquants utilisent la chaîne principalement pour voler des credentials d'administration (hashes de mots de passe), installer des backdoors PHP, défigurer des sites ou intégrer des installations compromises dans des réseaux de distribution de malware. Selon les données télémétriques de Wiz publiées fin juillet 2026, plus de 4,2 millions de sites WordPress utilisaient encore des versions vulnérables une semaine après la publication du patch, dont un nombre significatif d'installations gérées sur des hébergeurs mutualisés où les mises à jour automatiques sont désactivées.

D'après les analyses publiées par NetSPI, Picus Security et CyCognito, la particularité de wp2shell réside dans son universalité : contrairement à la plupart des vulnérabilités WordPress qui nécessitent un plugin tiers ou une configuration non standard, cette chaîne d'exploitation fonctionne sur une installation WordPress par défaut fraîchement déployée. Il n'existe aucun mécanisme de protection natif à WordPress pouvant bloquer l'attaque en l'absence du patch, et les configurations de durcissement courantes (désactivation XML-RPC, limitation des rôles utilisateurs) sont sans effet sur ce vecteur.

Impact et exposition

La surface d'attaque est massive : toute installation WordPress sur les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1, accessible via le web, est vulnérable à une exploitation pré-authentifiée. Aucune configuration particulière n'est requise — WordPress en installation par défaut est exploitable. Les sites hébergés sur des plateformes avec mises à jour automatiques activées ont probablement été corrigés automatiquement, mais les installations en auto-hébergement ou avec mises à jour manuelles sont à risque immédiat.

Les vecteurs d'attaque les plus courants identifiés en exploitation active incluent : vol de hashes administrateur suivi d'une attaque par dictionnaire hors ligne, écriture de webshells PHP (si les permissions de la base de données le permettent), création de comptes administrateur parasites via injection SQL, et exfiltration de données sensibles stockées dans WordPress (données WooCommerce, formulaires de contact, données utilisateurs). Dans les configurations WordPress hébergeant des boutiques e-commerce ou des formulaires collectant des données personnelles, une exploitation réussie peut constituer une violation RGPD sérieuse nécessitant une notification à la CNIL dans un délai de 72 heures.

L'exploitation est entièrement automatisable et déjà massivement automatisée selon les rapports de Cloudflare, Akamai et CyCognito. Des botnets scannent l'intégralité de l'espace d'adressage IPv4 à la recherche de sites WordPress vulnérables. Le délai entre une installation non patchée exposée en ligne et sa compromission peut se mesurer en heures voire en minutes dans l'environnement actuel. Les sites WordPress non patchés à la date du 31 juillet 2026 ont eu deux semaines d'exposition à une exploitation massive — le risque d'une compromission silencieuse déjà effectuée doit être sérieusement envisagé et investigué.

Au-delà de l'exploitation directe, les sites compromis via wp2shell sont utilisés comme infrastructure d'attaque secondaire : redirections malveillantes, hébergement de pages de phishing, distribution de malware via des publicités injectées, ou participation à des campagnes de spam SEO. La réputation de la marque et le référencement naturel des sites compromis sont fortement impactés, avec des délistages Google en cas de détection de distribution de malware ou de contenu de phishing.

Recommandations immédiates

• Mettre à jour WordPress vers la version 6.9.5 ou 7.0.2 immédiatement — via le tableau de bord WordPress (Tableau de bord > Mises à jour) ou WP-CLI : wp core update --version=7.0.2
• Vérifier que les mises à jour automatiques du cœur WordPress sont activées dans wp-config.php : define('WP_AUTO_UPDATE_CORE', true);
• Auditer les logs d'accès HTTP pour les requêtes POST vers /wp-json/batch/v1 contenant des paramètres author__not_in inhabituels depuis le 17 juillet 2026
• Vérifier la présence de nouveaux comptes administrateurs créés sans autorisation dans Tableau de bord > Utilisateurs depuis le 17 juillet
• Scanner l'arborescence WordPress pour des webshells PHP récemment créés : find /var/www/ -name "*.php" -newer /var/www/html/wp-config.php -ls
• Activer un WAF (Cloudflare, Wordfence, NinjaFirewall) avec des règles à jour pour bloquer les variantes d'exploitation connues — en complément du patch, pas à la place
• Pour les sites e-commerce ou gérant des données personnelles : considérer une investigation forensique si le site n'a pas été mis à jour dans les 48h suivant le 17 juillet 2026, et évaluer l'obligation de notification RGPD