La chaîne d'exploitation « wp2shell » constitue un incident de sécurité critique visant l'architecture fondamentale de l'écosystème WordPress. Il s'agit d'une vulnérabilité d'exécution de code à distance (RCE) avant authentification, résidant entièrement au sein du cœur de WordPress. Son exploitation ne nécessite ni plugin tiers, ni thème, ni accès authentifié. Une simple requête HTTP spécialement conçue, envoyée à une installation par défaut « standard », peut permettre à un attaquant non authentifié de prendre le contrôle total du système.

La gravité de cette menace se reflète dans son score CVSS de 9,8. La CISA a ajouté ces deux CVE à son catalogue des vulnérabilités connues exploitées (KEV) après avoir observé des activités d’exploitation peu après la divulgation. Les données indiquent qu’environ 60 % des organisations utilisant WordPress étaient initialement vulnérables au moment de la divulgation, une part importante d’entre elles exposant directement ces serveurs à Internet.

Une exploitation réussie peut permettre la compromission totale de la base de données, un accès persistant au serveur web via des webshells obfusquées, ainsi que la création non autorisée de comptes administratifs.

Présentation de la vulnérabilité

La chaîne d’exploitation wp2shell combine plusieurs vulnérabilités du cœur de WordPress pour parvenir à une élévation de privilèges sans authentification. L’attaque exploite d’abord une faille dans le traitement par lots des requêtes de l’API REST afin de contourner la validation des requêtes et les contrôles d’autorisation. Cet accès est ensuite utilisé pour exploiter une vulnérabilité d’injection SQL dans la gestion par WP_Query du paramètre author_exclude.

À l’aide de cette injection SQL, un attaquant peut manipuler des objets WordPress mis en cache et exploiter le mécanisme de mise en cache oEmbed pour réécrire des données malveillantes dans la base de données. L’exploit tire ensuite parti de la fonctionnalité de « changeset » du Customizer pour hériter temporairement des autorisations d’un compte administrateur, créant ainsi un utilisateur administratif persistant.

En résumé, l’attaque se déroule en quatre étapes :

1. Contournement de la validation de l’API REST via la désynchronisation des requêtes par lots.
2. Injection SQL due à une désinfection incorrecte des paramètres.
3. Empoisonnement du cache d'objets et manipulation de la base de données via le comportement de réécriture d'oEmbed.
4. Élévation de privilèges et persistance via la création d'un compte administrateur.

Combinées, ces vulnérabilités peuvent permettre à un attaquant non authentifié d'obtenir le contrôle administratif total d'une installation WordPress vulnérable.

Les vulnérabilités suivantes du cœur de WordPress sont exploitées dans cette attaque :

• CVE-2026-63030 (confusion de routes par lots dans l’API REST) : Une erreur de logique dans la fonction WP_REST_Server::serve_batch_request_v1(), où une gestion défaillante des objetsWP_Error entraîne une désynchronisation entre les tableaux internes de gestion des requêtes, permettant ainsi à des requêtes non validées d’hériter des autorisations de gestionnaires inoffensifs.
• CVE-2026-60137 (injection SQL dans WP_Query) : une faille de manipulation de types dans le moteur WP_Query. Lorsque certains paramètres reçoivent une chaîne brute au lieu du tableau attendu, la validation des entiers est contournée, ce qui entraîne l'interpolation de chaînes brutes dans les clausesWHERE des requêtes SQL .

Versions concernées et versions corrigées

Évaluation stratégique : risque lié à WordPress

Historiquement, la sécurité de WordPress s’est concentrée sur le « périmètre des plugins ». Cette exploitation démontre que des risques de sécurité importants peuvent provenir du cœur de WordPress lui-même et non pas uniquement des extensions tierces. Les organisations doivent veiller à ce que leurs instances WordPress soient intégrées dans des programmes formels de gestion des vulnérabilités et des correctifs.

D’un point de vue défensif, WordPress doit être considéré comme une cible de grande valeur. Son déploiement généralisé dans les environnements connectés à Internet en fait une plateforme attrayante pour les acteurs malveillants, ce qui augmente le risque de recherche de vulnérabilités, d’analyses automatisées et de tentatives d’exploitation.

Piliers stratégiques de la gouvernance

• Cartographie de la surface d’attaque : recensez en permanence tous les actifs WordPress. La majorité des compromissions se produisent sur des instances de préproduction oubliées et non corrigées.
• Validation continue : ne vous fiez pas au statut « mise à jour automatique ». Mettez en place une vérification automatisée des versions pour vous assurer que les correctifs sont bien actifs.
• Faites confiance, mais vérifiez : bien que WordPress.org permette les mises à jour forcées, les administrateurs doivent vérifier que celles-ci ont bien été menées à bien sur chaque configuration d’hôte.
• Rotation des identifiants et des salts : en cas de suspicion de vulnérabilité du noyau, la rotation des salts de la base de données dans le fichier wp-config.php constitue une mesure de défense stratégique obligatoire pour invalider les sessions existantes.

Recherche de menaces et indicateurs de compromission (IoC)

Signaux réseau

• StatutHTTP 207 « Multi-Status » : il s’agit d’un signal très fiable indiquant que des tentatives d’exploitation via l’API batch ont abouti.
• Prise en compte du contournement des WAF : les attaquants peuvent utiliser des échappements %2F dans le paramètre ?rest_route= pour contourner la simple correspondance de chaînes de caractères. Les WAF doivent être configurés pour effectuer un décodage des URL avant la correspondance.
• Agents utilisateur : surveillez la présence de wp2shell, rezwp2shell ou cve-2026-63030/1.0.

Artéfacts basés sur l’hôte

• Marqueurs de fichiers : recherchez « temp-write-test- » dans le répertoire wp-content/, utilisé par les kits d’exploitation pour vérifier les droits d’écriture.
• Plugins malveillants : recherchez les répertoires comportant un suffixe hexadécimal, tels que « wp-content/plugins/wp2shell_/ ».
• Distinction concernant CMSmap : les équipes d'analyse informatique doivent faire la distinction entre l'outil CMSmap légitime de 11 Ko et la plateforme obfusquée de 150 Ko observée dans les campagnes actuelles.

IOC connus

Mesures d'atténuation et de remédiation

Les organisations doivent immédiatement mettre à jour le cœur de WordPress vers les versions 7.0.2, 6.9.5 ou 6.8.6. Bien que WordPress.org ait déployé des mises à jour forcées, les administrateurs doivent « faire confiance mais vérifier » ces installations, car la réussite de la mise à jour automatique n’est pas garantie sur toutes les configurations d’hébergement. La priorité doit être donnée aux instances des branches 6.9.x et 7.0.x, qui sont vulnérables à la chaîne complète d'exécution de code à distance (RCE).

Mesures d'atténuation temporaires

Lorsque l'application immédiate d'un correctif n'est pas possible, les administrateurs doivent mettre en place des règles WAF afin de bloquer tout accès non authentifié aux points de terminaison batch de l'API REST concernés. Le décodage des URL doit être effectué avant la vérification de la correspondance avec les règles afin de détecter les requêtes encodées.

Points de terminaison bloqués :

• /wp-json/batch/v1
• ?rest_route=/batch/v1 (y compris les variantes encodées en URL telles que %2Fbatch%2Fv1)

Actions à entreprendre après une compromission

S'il y a des raisons de penser qu'une exploitation a eu lieu, les mesures suivantes sont recommandées :

• Vérifier l'intégrité des fichiers du cœur : exécutez la commande `wp core verify-checksums` pour identifier les fichiers du cœur de WordPress modifiés ou non autorisés.
• Renouveler les identifiants : réinitialisez les identifiants de la base de données et régénérez les sels d'authentification et les clés de sécurité dans le fichier wp-config.php.
• Vérifier les comptes utilisateurs : inspecter la table `wp_users` à la recherche de comptes non autorisés, en particulier ceux utilisant la convention de nommage `w2s_`.
• Rechercher les indicateurs de compromission (IOC) : recherchez dans les journaux du serveur web, les systèmes de fichiers et les outils de surveillance de la sécurité les indicateurs de compromission répertoriés dans cet avis.

Si l’une des menaces décrites dans ce bulletin vous préoccupe ou si vous avez besoin d’aide pour déterminer les mesures à prendre afin de vous protéger contre les menaces les plus graves pesant sur votre organisation, veuillez contacter votre chargé de compte ou nous contacter pour savoir comment protéger votre organisation.