CVE-2026-60137 : RCE non-auth WordPress WP2Shell CERT-FR

Les faits

Le 17 juillet 2026, les chercheurs en sécurité de VulnCheck ont divulgué une chaîne d'exploitation redoutable baptisée WP2Shell, combinant deux vulnérabilités dans le cœur de WordPress : CVE-2026-60137 et CVE-2026-63030. Le 20 juillet 2026, le CERT-FR a publié l'alerte CERTFR-2026-ALE-007 indiquant avoir connaissance d'une preuve de concept publique et anticiper des tentatives d'exploitation en masse à court terme.

CVE-2026-60137 est une injection SQL dans la classe WP_Query du cœur de WordPress, causée par un assainissement insuffisant du paramètre author__not_in lors des requêtes à l'API REST. Ce paramètre, destiné à filtrer les publications par auteur, n'est pas correctement validé côté serveur : un attaquant peut y injecter des fragments SQL arbitraires directement interprétés par la base de données MySQL ou MariaDB sous-jacente. La vulnérabilité porte un score CVSS v3.1 de 9.1 (Critical), avec un vecteur d'attaque réseau, sans authentification requise et une complexité d'attaque faible.

CVE-2026-63030 exploite une confusion de routes dans le point d'accès de traitement par lot (batch) de l'API REST WordPress, précisément dans la méthode WP_REST_Server::serve_batch_request_v1(). Le serveur REST accepte des requêtes groupées via /wp-json/batch/v1 et, en raison d'une logique de routage défaillante, permet à un attaquant d'injecter des routes internes arbitraires dans ce contexte de lot, contournant ainsi les vérifications de permissions normalement appliquées. Le CVSS standalone de cette vulnérabilité est de 7.5 (High), mais lorsqu'elle est chaînée avec CVE-2026-60137, le score combiné atteint 9.8 selon l'analyse de VulnCheck.

La chaîne d'attaque WP2Shell fonctionne en deux temps. Dans un premier temps, l'attaquant exploite l'injection SQL (CVE-2026-60137) via l'endpoint /wp-json/wp/v2/posts?author__not_in= pour extraire les identifiants de session ou les hachages de mot de passe administrateur depuis la base de données. Dans un second temps, il utilise la confusion de routes de l'API batch (CVE-2026-63030) pour déclencher l'exécution de code arbitraire côté serveur, sans nécessiter aucun plugin tiers installé. Le résultat est une exécution de code à distance (RCE) complète et non authentifiée sur n'importe quelle installation WordPress Core vulnérable.

La chronologie révèle la rapidité de la menace : le 17 juillet 2026, les deux CVE sont divulguées de façon coordonnée par VulnCheck avec une advisory publique. Le même jour, WordPress publie les versions correctives 6.8.6, 6.9.5 et 7.0.2 et, fait rarissime, force la distribution automatique de ces correctifs sur toutes les installations supportées via son mécanisme d'auto-mise à jour. Malgré cette réactivité exemplaire, dans les 24 heures suivant la divulgation, Help Net Security rapporte les premiers signes d'exploitation active dans la nature.

D'après les analyses publiées par NSFOCUS et IndusHands, le point d'entrée principal de l'exploitation est la route REST /wp-json/wp/v2/posts combinée au paramètre malveillant. Des outils d'automatisation permettent de scanner massivement les installations non patchées. Les attaquants ciblent particulièrement les hébergements mutualisés où les mises à jour automatiques sont désactivées, les installations WordPress personnalisées dont les opérateurs ont bloqué l'auto-update, et les versions en fin de vie non supportées antérieures à la branche 6.8.

Au niveau technique, la root cause de CVE-2026-60137 réside dans l'absence d'utilisation des méthodes préparées (prepared statements) avec paramètre lié pour le paramètre author__not_in dans la construction de requête SQL dynamique de WP_Query. Bien que WordPress utilise généralement $wpdb->prepare(), cette portion du code avait échappé à l'audit de sécurité interne. Pour CVE-2026-63030, la root cause est une validation insuffisante des routes dans le traitement des requêtes batch, permettant à serve_batch_request_v1() de résoudre des routes internes qui ne devraient pas être accessibles depuis un contexte batch externe.

Le CERT-FR précise dans l'alerte CERTFR-2026-ALE-007 que la vulnérabilité affecte WordPress 6.8.x avant 6.8.6, les versions 6.9.x avant 6.9.5, les versions 7.0.x avant 7.0.2, et les versions 7.1.x avant 7.1 beta2. Les versions antérieures à la branche 6.8, bien que non officiellement supportées, sont également vulnérables à CVE-2026-60137 si elles implémentent l'API REST, activée par défaut depuis WordPress 4.4. Le PoC démontrant l'injection SQL est disponible publiquement selon les sources de renseignement cyber, accélérant considérablement le développement d'outils d'exploitation automatisés par des acteurs de moindre sophistication technique.

Impact et exposition

WordPress propulse environ 43 % des sites web mondiaux, représentant des dizaines de millions d'installations potentiellement vulnérables. Contrairement à de nombreuses vulnérabilités WordPress nécessitant un plugin spécifique, WP2Shell exploite uniquement le cœur (Core) de WordPress, sans dépendance à des extensions tierces. Toute installation avec l'API REST activée et exécutant une version vulnérable est exposée, qu'elle utilise un thème personnalisé, un e-commerce WooCommerce, un blog ou un site institutionnel.

Les conditions d'exploitation sont particulièrement favorables aux attaquants : aucune authentification préalable n'est requise, aucune interaction utilisateur n'est nécessaire, et la complexité de l'attaque est faible. L'API REST WordPress est généralement exposée publiquement sur Internet et fréquemment exclue des règles WAF génériques. La disponibilité d'un PoC public accélère considérablement la capacité des acteurs malveillants à développer des outils de scan automatisé ciblant les installations non patchées à l'échelle mondiale.

L'exploitation réussie de la chaîne WP2Shell permet à un attaquant de lire et modifier la base de données MySQL, d'exécuter du code arbitraire sur le serveur avec les privilèges du processus PHP ou web, de déployer des web shells persistants, de pivoter vers d'autres systèmes sur le réseau interne de l'hébergeur, et de compromettre l'ensemble des sites WordPress hébergés sur le même serveur en cas d'hébergement mutualisé. L'activation de l'auto-update WordPress a permis une distribution massive du correctif, mais de nombreuses organisations désactivent délibérément cette fonctionnalité pour des raisons de compatibilité, laissant leurs sites entièrement exposés sans intervention manuelle.

Recommandations immédiates

• Mettre à jour WordPress vers la version 6.8.6, 6.9.5 ou 7.0.2 selon votre branche — advisory : WordPress Security Release 6.8.6 / 6.9.5 / 7.0.2 (17 juillet 2026)
• Si la mise à jour immédiate est impossible : bloquer les requêtes vers /wp-json/batch/v1 contenant le paramètre rest_route=/batch/v1 via un WAF — mitigation officielle CERT-FR CERTFR-2026-ALE-007
• Bloquer également les requêtes vers /wp-json/wp/v2/posts contenant le paramètre author__not_in avec des valeurs non numériques au niveau WAF
• Vérifier les logs d'accès Apache/Nginx pour des requêtes suspectes vers /wp-json/batch/v1 et /wp-json/wp/v2/ avec des payloads inhabituels
• Auditer les fichiers récemment modifiés sur le serveur web via la commande : find /var/www -name "*.php" -newer /var/www/wp-login.php -ls
• Forcer la rotation des mots de passe administrateurs et des clés secrètes WordPress dans wp-config.php si le site est exposé depuis le 17 juillet 2026