Analyse d’une attaque WordPress : exploitation chaînée des CVE-2026-60137 et CVE-2026-63030
Introduction
Le 23 juillet 2026, une installation WordPress a été victime d’une attaque automatisée ayant conduit à une compromission du site, à la création d’un compte administrateur et à l’installation de plusieurs plugins malveillants.
L’analyse des journaux montre une chaîne d’exploitation correspondant à l’attaque connue sous le nom de WP2Shell.
Deux vulnérabilités du cœur de WordPress sont au centre de cette attaque :
- CVE-2026-60137 : vulnérabilité d’injection SQL affectant le traitement de certaines requêtes WordPress ;
- CVE-2026-63030 : vulnérabilité affectant le mécanisme de sécurité de l’API REST Batch.
Ces deux vulnérabilités peuvent être chaînées afin d’obtenir une exécution de code à distance avant authentification.
Le serveur analysé utilisait WordPress 6.9.4, version vulnérable au moment de l’attaque.
1. Le contexte : WordPress 6.9.4
Au moment de la compromission, la version installée était :
WordPress 6.9.4
La vérification d’intégrité du cœur WordPress a ensuite retourné :
Success: WordPress installation verifies against checksums.
Ce résultat est important : il indique que les fichiers officiels du cœur WordPress présents au moment de la vérification correspondent aux sommes de contrôle attendues.
Cependant, cela ne signifie pas que le site n’a pas été compromis.
Une attaque peut exploiter une vulnérabilité du cœur WordPress sans modifier les fichiers officiels de WordPress.
C’est précisément ce qui s’est produit ici.
2. Première vulnérabilité : CVE-2026-60137
La première brique de la chaîne d’exploitation est CVE-2026-60137.
Il s’agit d’une vulnérabilité affectant le traitement des requêtes WordPress et permettant à un attaquant distant de provoquer une injection SQL dans certaines conditions.
L’intérêt de cette vulnérabilité pour l’attaquant est de pouvoir accéder à des informations qui ne devraient normalement pas être accessibles sans disposer des privilèges nécessaires.
Cette étape constitue donc une première primitive d’exploitation.
Elle ne correspond pas à une simple tentative de connexion à /wp-login.php.
L’attaquant exploite directement le comportement vulnérable de WordPress.
3. Deuxième vulnérabilité : CVE-2026-63030
La seconde vulnérabilité est CVE-2026-63030.
Elle concerne le mécanisme de traitement des requêtes REST Batch.
Les journaux du serveur montrent de nombreuses requêtes de la forme :
POST /?rest_route=/batch/v1
POST /wp-json/batch/v1
Certaines requêtes contenaient également un paramètre associé à la campagne d’exploitation :
_w2s=[identifiant]
Le code HTTP retourné était notamment :
207 Multi-Status
Ce trafic est particulièrement significatif car il correspond au mécanisme utilisé par l’attaque WP2Shell.
La vulnérabilité REST Batch permet de franchir une étape supplémentaire dans la chaîne d’exploitation et, combinée à CVE-2026-60137, peut conduire à une exécution de code à distance.
4. Une attaque pré-authentification
L’un des points les plus importants de cet incident est que l’exploitation pouvait commencer sans authentification WordPress normale.
La chaîne n’était donc pas :
vol de mot de passe
↓
connexion WordPress
↓
2FA
↓
administration
mais plutôt :
requête HTTP malveillante
↓
CVE-2026-60137
↓
CVE-2026-63030
↓
contournement des contrôles
↓
exécution de code
↓
actions administratives
C’est pourquoi la présence d’un mécanisme 2FA ne permettait pas, à elle seule, d’empêcher cette attaque.
5. La chaîne WP2Shell observée
Les journaux permettent de reconstituer une séquence particulièrement révélatrice.
Une série de requêtes REST Batch est observée :
18:01:18 REST Batch
18:01:20 REST Batch
18:01:21 REST Batch
18:01:22 REST Batch
18:01:23 REST Batch
...
18:01:35 REST Batch
Quelques secondes plus tard :
18:01:37 POST /wp-login.php
18:01:40 POST /wp-admin/update.php?action=upload-plugin
Les chemins exacts sont volontairement anonymisés dans cet article.
Cette chronologie est un indicateur très fort d’une exploitation automatisée.
L’accès à l’interface de connexion n’implique donc pas nécessairement que l’attaquant ait réussi une authentification traditionnelle.
Dans cette chaîne, il s’agit d’une étape faisant suite à l’exploitation.
6. Installation des plugins malveillants
Après l’exploitation, plusieurs plugins malveillants ont été installés.
Leurs noms sont anonymisés ici :
site-tweaks-[identifiant]
content-tools-[identifiant]
wp-optimizer-[identifiant]
Ces plugins constituaient une capacité supplémentaire permettant à l’attaquant de conserver ou d’étendre son accès au site.
L’installation d’un plugin est particulièrement critique dans WordPress car un plugin PHP peut exécuter du code avec les privilèges du processus WordPress.
L’attaquant n’avait donc plus besoin de maintenir uniquement la chaîne d’exploitation initiale.
Une fois du code malveillant installé, celui-ci pouvait potentiellement fournir une persistance.
7. Création d’un compte administrateur
Un compte administrateur a également été découvert.
Son nom et son adresse sont anonymisés dans cet article :
w2s_[identifiant aléatoire]
Le compte possédait le rôle :
administrator
et avait été créé le :
23 juillet 2026
à proximité temporelle de l’activité malveillante observée dans les journaux.
Ce compte constitue un indicateur de compromission important.
Il est toutefois essentiel de distinguer :
le vecteur initial
des
mécanismes de persistance créés après la compromission.
Le compte administrateur et les plugins malveillants sont des conséquences de l’exploitation des vulnérabilités ; ils ne constituent pas nécessairement le point d’entrée initial.
8. Pourquoi le changement de l’URL d’administration ne suffit pas
Une mesure parfois utilisée consiste à déplacer ou masquer l’URL d’administration WordPress.
Cette mesure peut réduire certains scans automatisés ciblant directement l’interface d’administration.
Elle ne corrige cependant pas une vulnérabilité du cœur de WordPress.
Dans le cas présent, l’attaque passait notamment par l’API REST :
/wp-json/
et par le mécanisme :
rest_route=/batch/v1
L’attaquant pouvait donc commencer son exploitation sans avoir besoin de connaître l’URL personnalisée de l’administration.
La modification de l’URL d’administration ne doit donc pas être considérée comme une protection contre CVE-2026-60137 ou CVE-2026-63030.
9. Pourquoi le 2FA ne protège pas contre le vecteur initial
Le 2FA reste une protection essentielle contre le vol ou la réutilisation d’identifiants.
Mais il intervient au niveau de l’authentification.
Dans cette attaque, le problème se situe avant cette étape.
La chaîne peut être représentée ainsi :
INTERNET
│
▼
requête malveillante
│
▼
CVE-2026-60137
│
▼
CVE-2026-63030
│
▼
exécution de code distante
│
▼
privilèges administratifs
│
▼
installation de plugins
│
▼
persistance
Le 2FA protège principalement :
mot de passe
+
second facteur
↓
connexion utilisateur
Il ne corrige pas une vulnérabilité permettant à un attaquant de contourner le processus d’authentification.
Il est donc tout à fait possible d’avoir un site correctement protégé par 2FA et néanmoins vulnérable à une faille critique du cœur WordPress.
10. Vérification de l’intégrité du cœur WordPress
Après l’incident, une vérification des fichiers officiels WordPress a été effectuée :
wp core verify-checksums
Résultat :
Success: WordPress installation verifies against checksums.
Aucune modification des fichiers du cœur n’a donc été détectée par cette vérification.
Cela constitue un élément rassurant.
Cependant, cette commande ne vérifie pas :
- les plugins ;
- les thèmes ;
- la base de données ;
- les comptes utilisateurs ;
- les tâches cron ;
- les fichiers uploadés ;
- les mécanismes de persistance ajoutés par un plugin ;
- les autres fichiers PHP présents dans l’hébergement.
Une analyse post-compromission doit donc être plus large.
11. Recherche des traces de l’attaque
Plusieurs recherches ont été réalisées dans les fichiers PHP.
La recherche des chaînes :
wp2shell
et de l’identifiant du compte compromis n’a retourné aucun résultat.
Une recherche plus large de :
_w2s
n’a également retourné aucune occurrence dans les fichiers actuellement présents.
Cela signifie que les marqueurs recherchés n’étaient plus présents dans les fichiers examinés.
Cette information est encourageante, mais elle ne constitue pas à elle seule une preuve absolue de l’absence de compromission.
12. Recherche des fichiers créés pendant l’attaque
Une recherche ciblée sur la période correspondant à l’exploitation a également été effectuée dans le répertoire du site.
Aucun fichier correspondant à cette fenêtre temporelle n’a été trouvé dans les répertoires examinés.
Il faut toutefois rester prudent avec les dates mtime.
Une date de modification de fichier peut être conservée, modifiée ou ne pas correspondre exactement au moment de l’installation du fichier.
Les journaux HTTP et les informations de la base de données restent donc indispensables pour reconstituer la chronologie.
13. Les deux vulnérabilités forment une chaîne
L’élément essentiel de cet incident est que les deux CVE ne doivent pas être analysées isolément.
La chaîne est :
CVE-2026-60137
│
▼
primitive d'exploitation
│
▼
CVE-2026-63030
│
▼
contournement via REST Batch
│
▼
exécution de code à distance
│
▼
actions privilégiées
│
▼
installation de plugins
│
▼
création d'un compte administrateur
C’est cette combinaison qui rend l’attaque particulièrement dangereuse.
Une vulnérabilité permettant une fuite ou une manipulation de données peut être beaucoup plus grave lorsqu’elle peut être combinée avec une seconde vulnérabilité permettant de franchir les contrôles de sécurité.
14. La leçon principale : les mises à jour sont prioritaires
Cet incident montre pourquoi les mises à jour de sécurité du cœur WordPress doivent être appliquées rapidement.
Une politique consistant à vérifier WordPress chaque semaine est une bonne pratique pour les mises à jour courantes.
Mais lorsqu’une vulnérabilité critique est activement exploitée, il ne faut pas nécessairement attendre le prochain cycle hebdomadaire.
La priorité doit être :
Vulnérabilité critique annoncée
↓
évaluation immédiate
↓
sauvegarde
↓
mise à jour
↓
vérification
↓
surveillance des logs
Dans le cas présent, rester en WordPress 6.9.4 alors que la version corrigée était disponible exposait directement le site à cette chaîne d’exploitation.
15. Mesures correctives recommandées
Après une compromission de ce type, les mesures suivantes sont recommandées.
1. Mettre WordPress à jour
Installer immédiatement une version corrigée du cœur WordPress.
2. Mettre à jour tous les plugins et thèmes
Un plugin vulnérable peut fournir un second point d’entrée même après la correction du cœur.
3. Supprimer les plugins malveillants
Ne pas simplement les désactiver.
Ils doivent être supprimés après conservation éventuelle d’une copie destinée à l’analyse forensique.
4. Réinitialiser les comptes administrateurs
Tous les comptes administrateurs doivent être vérifiés.
Tout compte inconnu doit être supprimé après conservation des éléments nécessaires à l’analyse.
5. Réinitialiser les mots de passe
Les mots de passe des comptes WordPress et des comptes techniques concernés doivent être renouvelés.
6. Révoquer les sessions
Les sessions WordPress existantes doivent être invalidées.
7. Vérifier les clés et secrets
Les clés de sécurité WordPress et les autres secrets susceptibles d’avoir été exposés doivent être renouvelés.
8. Examiner la base de données
Il faut notamment rechercher :
- utilisateurs administrateurs inconnus ;
- options suspectes ;
- tâches planifiées ;
- contenus injectés ;
- paramètres de plugins malveillants.
9. Examiner les fichiers
Une recherche doit couvrir :
wp-content/plugins/
wp-content/themes/
wp-content/mu-plugins/
wp-content/uploads/
ainsi que les fichiers PHP situés à la racine du site.
10. Surveiller les journaux
Les accès aux endpoints REST et les requêtes inhabituelles doivent être surveillés après la mise à jour.
Conclusion
L’incident analysé correspond à une attaque par chaînage de vulnérabilités contre WordPress 6.9.4.
Les deux vulnérabilités identifiées sont :
- CVE-2026-60137
- CVE-2026-63030
Leur combinaison permet une chaîne d’exploitation pouvant aboutir à une exécution de code à distance avant authentification.
Les journaux montrent ensuite l’accès à des fonctionnalités administratives, l’installation de plusieurs plugins malveillants et la création d’un compte administrateur.
Cette chronologie explique plusieurs points importants :
- le changement de l’URL
wp-adminne suffisait pas ; - le 2FA ne pouvait pas empêcher le vecteur initial ;
- le mot de passe du compte administrateur n’était pas nécessairement le point d’entrée ;
- la vérification des checksums du cœur WordPress peut rester positive malgré une compromission ;
- les plugins et les comptes administrateurs doivent être contrôlés après l’incident ;
- surtout, la correction des vulnérabilités du cœur WordPress est la défense prioritaire contre ce type d’attaque.
L’incident illustre ainsi un principe fondamental de la sécurité WordPress :
Le 2FA protège l’authentification. Les mises à jour protègent contre les vulnérabilités. Une sécurité efficace nécessite les deux.