WP2SHELL – Détection et investigation

WP2Shell est le nom donné à une chaîne d'exploitation affectant le cœur de WordPress. Elle repose sur l'enchaînement de deux vulnérabilités : CVE-2026-63030 et CVE-2026-60137. Exploitées ensemble, elles permettent à un attaquant non authentifié de compromettre une instance WordPress vulnérable et d'obtenir, dans certains scénarios, une exécution de code à distance.

CVE-2026-63030

Cette première vulnérabilité concerne le mécanisme de traitement des requêtes par lot de la REST API de WordPress, accessible via l'endpoint /wp-json/batch/v1. En raison d'un défaut dans la gestion des contrôles d'autorisation, un attaquant peut contourner certaines vérifications de sécurité et accéder à des fonctionnalités qui devraient normalement être réservées à des utilisateurs authentifiés.

CVE-2026-60137

Cette seconde vulnérabilité est une injection SQL présente dans la classe WP_Query. Elle affecte le traitement du paramètre author__not_in, utilisé lors de la construction de certaines requêtes SQL. Cette vulnérabilité est difficilement exploitable sur une installation WordPress standard, car le chemin permettant d'atteindre le code vulnérable est normalement protégé.

Les versions WordPress impactées sont les versions des branches :

• 6 : de la version 6.9.0 (2 février 2026) à la version 6.9.4 (20 avril 2026)

• 7 : de la version 7.0.0 (17 juin 2026) à la version 7.0.1 (9 juillet 2026)

Les correctifs, disponibles depuis vendredi 17 juillet sont à installer dès que possible sur les instances vulnérables : 7.0.2 pour la branche 7 ou bien la 6.9.5 pour la branche 6.

À la suite de la sortie de Proof of concepts sur Internet depuis plusieurs jours, les scans d'applications web ont débuté et sont maintenant visibles dans les journaux des serveurs :

Objectif et conséquence de l’exploitation

L’injection SQL (CVE-2026-60137) de WP2Shell permet à un attaquant d’exécuter des requêtes non prévues sur la base de données utilisée par WordPress.  

Dans un premier temps, elle peut servir à lire des informations sensibles : comptes utilisateurs, adresses e-mail, condensats de mots de passe, contenus privés, données de plugins ou paramètres système du site.  

Elle permet également d’exécuter du code SQL permettant de :

• Modifier un compte utilisateur/administrateur

• Créer un nouveau compte

• Modifier la configuration du site

A partir de la modification système du site et de la création d’un compte administrateur, l’attaquant peut alors installer de nouveaux plugins, déposer des fichiers type webshell afin d’obtenir un accès sur le serveur où WordPress est déployé.

Méthodes de détection

Détection côté Proxy / Reverse Proxy

L’exploitation de la vulnérabilité repose sur les endpoints ?rest_route=/batch/v1 et /wp-json/batch/v1 de l’API REST de WordPress. Il est donc possible de détecter des tentatives d'exploitation en surveillant les requêtes adressées à ces points d'entrée.

Dans la majorité des déploiements WordPress, la journalisation du serveur web est relativement limitée et ne conserve généralement que les journaux d'accès (access logs). Ces derniers permettent néanmoins d'identifier les requêtes ciblant les endpoints vulnérables, leur méthode HTTP, le code de réponse retourné ainsi que l'adresse IP source :

Les exploitations observées utilisent une requête HTTP POST vers l'un de ces endpoints et retournent généralement un code 207 Multi-Status. Ce code de réponse indique que plusieurs sous-requêtes contenues dans la requête batch ont été traitées et que leurs résultats sont regroupés dans une réponse unique. Ce comportement constitue un point intéressant d’une possible compromission de la plateforme.

Aperçu d'un évènement de journaux NGINX d'une exploitation wp2shell :

127.0.0.1 - - [19/Jul/2026:23:39:45 +0200] "POST /?rest_route=/batch/v1 HTTP/1.1" 207 8622 "-" "wp2shell" 

La règle SIGMA suivante permet d'identifier des succès d'execution sur l'endpoint vulnérable :

name:  WordPress WP2Shell Pre-Authentication RCE Exploitation Attempt 

author: OWN-CERT 

detection: 

  selection: 

    url.original|contains:  

      - '/wp-json/batch/v1' 

      - '?rest_route=/batch/v1' 

    http.response.status_code: '207' 

    http.request.method: 'POST' 

  condition: 'selection' 

Certains PoCs déjà disponibles sur Internet sont maintenant réutilisés et leurs exécutions laissent des traces caractéristiques à une configuration par défaut, comme la présence d’un user-agent dédié, « wp2shell »...

Aperçu du user-agent spécifique à un PoC d'exploitation de wp2shell :

127.0.0.1 - - [19/Jul/2026:16:21:53 +0200] "POST /?rest_route=/batch/v1 HTTP/1.1" 207 8500 "-" "wp2shell" 

127.0.0.1 - - [19/Jul/2026:16:21:53 +0200] "POST /?rest_route=/batch/v1 HTTP/1.1" 207 8479 "-" "wp2shell" 

127.0.0.1 - - [19/Jul/2026:16:21:25 +0200] "GET / HTTP/1.1" 200 14475 "http://127.0.0.1/page-d-exemple/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0" 

127.0.0.1 - - [19/Jul/2026:16:21:24 +0200] "GET /page-d-exemple/ HTTP/1.1" 200 15022 "http://127.0.0.1/category/non-classe/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:152.0) Gecko/20100101 Firefox/152.0" 

Bien que les journaux du serveur web offrent une visibilité limitée sur le contenu des échanges, la taille des réponses HTTP peut fournir un indice sur les actions réalisées par un attaquant. En effet, une requête visant uniquement à identifier le moteur de base de données (requête n°1) génère généralement une réponse de taille bien inférieure à une requête destinée à extraire des données depuis un webshell déposé.

La plupart des requêtes oscillent entre 8000 et 8700 bytes retournés

127.0.0.1 - - [20/Jul/2026:17:55:13 +0200] "POST /?rest_route=/batch/v1 HTTP/1.1" 207 8456 "-" "wp2shell" 

 L'exploitation de la vulnérabilité peut conduire à plusieurs actions post-compromission, notamment la création d'un nouveau compte administrateur. Il est donc recommandé d'examiner les connexions au panneau d'administration, via l’endpoint /wp-admin intervenues dans les minutes ou les heures suivant une tentative d'exploitation.

Ces connexions peuvent correspondre à une intervention manuelle de l'attaquant, par exemple après la récupération d'identifiants, ou être entièrement automatisées. Les chaînes d'exploitation permettent en effet d'enchaîner les différentes étapes de la compromission en quelques secondes, depuis l'exploitation initiale jusqu'à la création d'un compte administrateur et sa première connexion :

Dans l’exemple ci-dessus, l’attaquant va créer un nouvel utilisateur via une requête SQL exécutée sur la base MariaDB, puis la connexion de ce nouveau compte est automatisée afin de générer une connexion sur l’endpoint /wp-login.php, puis ajouter un nouveau plugin via la page /wp-admin/plugin-install.phpet  /wp-admin/update.php?action=upload-plugin.

Règle de détection d'installation d'un nouveau plugin WordPress :

name: WordPress New Plugin Installation 

author: OWN-CERT 
detection: 

  selection_update: 

    url.original|contains:  

      - '/wp-admin/update.php?action=upload-plugin' 

    http.response.status_code: '200' 

    http.request.method: 'POST' 

  selection_install: 

    url.original|contains: 

      - '/wp-admin/plugin-install.php?tab=upload' 

    http.response.status_code: '200' 

    http.request.method: 'GET' 

  condition: 1 of selection_* 

127.0.0.1 - - [19/Jul/2026:16:25:36 +0200] "GET /wp-admin/plugin-install.php?tab=upload HTTP/1.1" 200 180790 "-" "wp2shell" 

Ces actions peuvent être légitimes dans le cadre d’une opération d’administration IT mais peuvent être considérées comme malveillantes dans la période qui suit les exploitations via l’accès à l’endpoint /?rest_route=/batch/v1.

Lors du dépôt du webshell par l’attaquant, les commandes sont passées par des requêtes GET laissant la commande visible dans l’URL.

Requête vers le webshell déposé :

127.0.0.1 - - [19/Jul/2026:16:25:38 +0200] "GET /wp-content/plugins/wp2shell_2ef5584c/wp2shell_2ef5584c.php?t=7ffc4720464bff372771e5e4a6749d4e&c=whoami HTTP/1.1" 200 35 "-" "wp2shell" 

La recherche de commandes de reconnaissance dans les journaux web peuvent permettre d’identifier le début de la phase de reconnaissance.

Règle de détection de potentiel webshell dans les plugins WordPress :

name: Suspicious Request to Potential WordPress Web Shell 

author: OWN-CERT 
detection: 

  selection: 

    http.response.status_code|startswith: '2' 

    url.original|contains: 

      - '/wp-content/plugins' 

  selection_command: 

    url.original|contains: 

      - '&c=' 

      - 'whoami' 

      - 'uname' 

      - 'hostname' 

      - 'hostnamectl' 

      - 'pwd' 

      - 'env' 

      - 'printenv' 

      - 'ifconfig' 

      - 'groups' 

      - '/etc/' 

      - 'find' 

      - 'lscpu' 

      - 'lsblk' 

  condition: selection and selection_command

Détection applicatif

L'identification d'une compromission ou d'activités malveillantes à partir des seuls mécanismes natifs de WordPress est relativement limitée. En effet, WordPress ne dispose pas, par défaut, d'un système de journalisation détaillé des actions d'administration. Des événements tels que la création d'un compte administrateur, la modification des privilèges d'un utilisateur ou encore certains changements de configuration ne sont donc pas conservés dans des journaux exploitables.

Pour bénéficier de cette visibilité, il est nécessaire de mettre en place, en amont de l'incident, une solution de journalisation dédiée telle que WP Activity Log, Simple History ou tout autre plugin équivalent. Sans ces journaux, l'investigation post-mortem repose principalement sur les journaux http et les éventuelles solutions de supervision (EDR, SIEM, etc.), ce qui limite fortement la capacité à reconstituer précisément les actions réalisées par un attaquant.

Détection côté Système

Exécutions des commandes SQL

L’exécution de requêtes SQL sur le serveur de base de données MariaDB configuré par défaut n’est pas journalisé sur le système ou dans des tables d’audit SQL, qui pourraient contenir historique de commandes.

Une activité SQL est cependant observée sur le disque dans le cadre du fonctionnement de la base. En effet, MariaDB écrit, en fonction de l’activité SQL, des tables temporaires internes par le moteur interne Aria dans un dossier spécifié dans la configuration MariaDB (Cf fichier de configuration /etc/mysql/mariadb.conf.d/50-server.cnf) :

Cette activité est "continue" dans le sens où une activité classique de la base entraine des opérations régulières de requête, de mises à jour... Ainsi le contenu de ces fichiers est légitime.

Deux types de fichiers sont créés et supprimés à quelques millisecondes près lors de ces activités :

• Fichiers .MAI : Ces fichiers contiennent par exemple les index, la définition physique de la table, des informations sur les colonnes…

• Fichiers .MAD : Ces fichiers contiennent notamment les valeurs manipulées par MariaDB

Bien qu’ils ne soient pas au format texte classique mais au format Aria, il est possible d’exporter des chaines de caractères via l’outil strings afin d’en savoir plus sur leur contenu.

Attention, ces fichiers sont des fichiers systèmes temporaires de la base de données et non voués à être collectés/archivés dans le cadre d’une politique de journalisation.

Dans le cadre d'une surveillance SOC en temps réel, la durée de vie des fichiers (en millisecondes) rend l'analyse et/ou la récupération impossible. Il est cependant intéressant de savoir que des résultats de commandes SQL, peuvent y être retrouvés dans le cas où des fichiers.

C'est pourquoi la suite de l'analyse de ces fichiers ci-dessous est proposée dans un objectif de découverte et non de méthodologie pour une investigation.  Dans le cadre de cette experimentation, une bibliothèque a été injectée dans le processus mariadbd afin d'intercepter les appels de suppression de fichiers (unlink() et unlinkat()) pour les stocker dans un espace dédié avant la tentative de suppression.

Via la commande strings, il est retrouvé un encodage hexadécimal d’une fuite de données des identifiants des comptes administrateurs de l’instance WordPress, à la fin d’un fichier .MA :

strings -a /tmp/#sql-temptable-27314-22-8.MAD 

  

[…] 

request 

2026-07-19 16:25:36 

0000-00-00 00:00:00 

Brouillon auto 

auto-draft 

open 

open 

2026-07-19 16:25:36 

0000-00-00 00:00:00 

http://127.0.0.1/?p=9 

post 

2020-01-01 00:00:00 

2020-01-01 00:00:00 

||317C706F632D76756C6E65726162696C6974797C247770243279243130242E655A4B4E4B4F302E79437665767A364C6F794D744F7748544D334477494B314277534F596C34393365344D6A744F7A7157374475|| 

publish 

2020-01-01 00:00:00 

2020-01-01 00:00:00 

post 

Il est ensuite possible de décoder la chaine qui donne :

1|poc-vulnerability|$wp$2y$10$.eZKNKO0.yCvevz6LoyMtOwHTM3DwIK1BwSOYl493e4MjtOzqW7Du 

Les différents champs sont :  

• 1 : identifiant du compte

• poc-vulnerability : nom d'utilisateur / login

• $wp$2y$10$.eZKNKO0.yCvevz6LoyMtOwHTM3DwIK1BwSOYl493e4MjtOzqW7Du : hash du mot de passe WordPress

Et ont été collectés à la suite de l’exploitation de la vulnérabilité d’injection SQL afin de récupérer les mots de passe des comptes administrateurs de l’instance.

Il est possible d'identifier du contenu suspect au travers de l'observation de chaines hexadécimales entre pipes, commun à l'exploitation de la vulnérabilité par une règle YARA :

rule MariaDB_Temporary_MAD_Hex_Blob 

{ 

    meta: 

        description = "Detects a hexadecimal blob enclosed by double pipes in a MariaDB temporary MAD data file" 

        author = "OWN-CERT" 

        date = "21/07/2026" 

        os = "Linux" 

  

    strings: 

        $mad_header = { 

            03 01 87 01 3C FE 80 00 

            00 00 00 00 00 00 01 80 

            00 00 00 00 00 00 00 01 

            13 

        } 

  

        $hex_blob = /\|\|[0-9A-Fa-f]{64,4096}\|\|/ 

  

    condition: 

        $mad_header at 0 

        and $hex_blob 

} 

Par ailleurs, une règle spécifique peut être créée pour identifier une récupération d'information liée au compte administrateur de l'instance, ici poc-vulnerability.

Ainsi, l'observation d'un motif hexadécimal peut lever un résultat :

||313A706F632D76756C6E65726162696C6974793A 

Qui correspond à "1:poc-vulnerability:"

rule MariaDB_Temporary_MAD_Target_Admin_Account 

{ 

    meta: 

        description = "Detects a hexadecimal blob related to the Wordpress administrator account, poc-vulnerability" 

        author = "OWN-CERT" 

        date = "21/07/2026" 

        os = "Linux" 

    strings: 

        $mad_header = { 

            03 01 87 01 3C FE 80 00 

            00 00 00 00 00 00 01 80 

            00 00 00 00 00 00 00 01 

            13 

        } 

  

        $target = "||313A706F632D76756C6E65726162696C6974793A" 

  

    condition: 

        $mad_header at 0 

        and $target 

} 

Exécutions des commandes systèmes

L'exécution de commandes via un webshell est généralement visible par les solutions de sécurité. En effet, chaque commande lancée entraîne la création d'un ou plusieurs processus sur le système d'exploitation. Ces processus sont surveillés par des outils tels que les EDR, qui peuvent détecter des comportements anormaux ou suspects, comme l'exécution d'un interpréteur de commandes ou d'utilitaires système par une application web.

Ces commandes sont exécutées depuis un processus parent qui correspond au gestionnaire de processus, par exemple PHP-FPM, souvent utilisés dans des environnements Nginx / PHP et qui utilise le compte utilisateur configuré pour, par exemple www-data.

Ainsi au niveau EDR, il est retrouvé l’arborescence des processus suivant :

php-fpm (master) 

    └── php-fpm (pool) 

          └── /bin/sh 

                └── whoami 

Il est donc possible d’identifier des processus enfants suspects en provenance du gestionnaire PHP-FPM qui ne sont pas légitimes.

Aperçu d'une règle de détection d'un shell enfant au processus PHP-FPM :

name: Suspicious Child Process Spawned by PHP-FPM 

author: OWN-CERT 

detection: 

  selection: 

    process.parent.executable|startswith: '/usr/sbin/php-fpm' 

    process.name:  

      - 'sh' 

      - 'bash' 

      - 'dash' 

  selection_filter: 

    process.command_line|contains: 

      - 'commande_legitime' 

  condition: selection and not selection_filter 

Attention, l’utilisation légitime de PHP-FPM peut générer de nombreux sous processus légitimes par rapport au contexte métier de l’application qu’il est nécessaire de prendre en compte afin de limiter les faux positifs. Cette règle est plus générique et s’inscrit dans la démarche de surveillance de webshell des différents serveurs webs comme Apache, Tomcat etc.

L'exploitation de WP2Shell laisse plusieurs traces identifiables, aussi bien au niveau des journaux HTTP que lors de l’exécution système. Il est ainsi possible de mettre en place des mécanismes de détection en temps réel afin d'identifier des tentatives d'exploitation, notamment en surveillant les requêtes adressées à l'API REST de WordPress ou certains comportements anormaux observés sur l'hôte à la suite de l’utilisation de reverse shell.

En revanche, l'investigation a posteriori est plus complexe : les journaux système et ceux de WordPress restent relativement limités, voire inexistant, pour reconstituer le déroulement d'une attaque.  

Sans traces réseau, journaux d'accès détaillés ou solutions de supervision telles qu'un EDR, il est difficile de déterminer avec certitude si une exploitation a abouti, quelles actions ont été réalisées et quelles données ont été consultées ou modifiées, notamment dû au manque de visibilité sur les interactions entre WordPress et la base de données.

Afin de protéger au mieux les instances WordPress, il est recommandé de :

• Mettre à jour dès que possible les instances dans la dernière version disponible, c’est-à-dire la 7.0.2 ou bien la 6.9.5.

• Si ce n’est pas possible, appliquer une protection temporaire en bloquant l’accès aux deux endpoints vulnérables évoqués.

Annexe

Règles de détection (format Sekoia.IO)

WordPress WP2Shell Pre-Authentication RCE Exploitation Attempt (SIGMA)

name: WordPress WP2Shell Pre-Authentication RCE Exploitation Attempt 

description: Detects HTTP requests consistent with attempts to exploit the WP2Shell vulnerability chain (CVE-2026-63030 and CVE-2026-60137) targeting vulnerable WordPress Core REST API batch endpoints. This activity may indicate reconnaissance or exploitation attempts leading to unauthenticated remote code execution on affected WordPress installations. 

author: OWN-CERT 
detection: 

  selection: 

    url.original|contains:  

      - '/wp-json/batch/v1' 

      - '?rest_route=/batch/v1' 

    http.response.status_code: '207' 

    http.request.method: 'POST' 

  condition: 'selection' 

WordPress New Plugin Installation (SIGMA)

name: WordPress New Plugin Installation 

description: Detects the installation of a new WordPress plugin, which may indicate legitimate administrative activity or the deployment of a malicious plugin following a successful compromise. This event should be reviewed, especially if it occurs outside of approved maintenance windows or is performed by an unexpected user. 

author: OWN-CERT 
detection: 

  selection_update: 

    url.original|contains:  

      - '/wp-admin/update.php?action=upload-plugin' 

    http.response.status_code: '200' 

    http.request.method: 'POST' 

  selection_install: 

    url.original|contains: 

      - '/wp-admin/plugin-install.php?tab=upload' 

    http.response.status_code: '200' 

    http.request.method: 'GET' 

  condition: 1 of selection_* 

Suspicious Request to Potential WordPress Web Shell (SIGMA)

name: Suspicious Request to Potential WordPress Web Shell 

description: Detects HTTP requests targeting files or paths commonly associated with WordPress web shells. Such requests may indicate post-exploitation activity, attacker interaction with a deployed web shell, or attempts to execute arbitrary commands on a compromised WordPress instance. This activity should be investigated to confirm whether unauthorized code has been uploaded and executed. 

author: OWN-CERT 
detection: 

  selection: 

    http.response.status_code|startswith: '2' 

    url.original|contains: 

      - '/wp-content/plugins' 

  selection_command: 

    url.original|contains: 

      - '&c=' 

      - 'whoami' 

      - 'uname' 

      - 'hostname' 

      - 'hostnamectl' 

      - 'pwd' 

      - 'env' 

      - 'printenv' 

      - 'ifconfig' 

      - 'groups' 

      - '/etc/' 

      - 'find' 

      - 'lscpu' 

      - 'lsblk' 

  condition: selection and selection_command 

Suspicious Child Process Spawned by PHP-FPM (SIGMA)

name: Suspicious Request to Potential WordPress Web Shell 

description: Detects HTTP requests targeting files or paths commonly associated with WordPress web shells. Such requests may indicate post-exploitation activity, attacker interaction with a deployed web shell, or attempts to execute arbitrary commands on a compromised WordPress instance. This activity should be investigated to confirm whether unauthorized code has been uploaded and executed. 

author: OWN-CERT 
detection: 

  selection: 

    http.response.status_code|startswith: '2' 

    url.original|contains: 

      - '/wp-content/plugins' 

  selection_command: 

    url.original|contains: 

      - '&c=' 

      - 'whoami' 

      - 'uname' 

      - 'hostname' 

      - 'hostnamectl' 

      - 'pwd' 

      - 'env' 

      - 'printenv' 

      - 'ifconfig' 

      - 'groups' 

      - '/etc/' 

      - 'find' 

      - 'lscpu' 

      - 'lsblk' 

  condition: selection and selection_command 

MariaDB_Temporary_MAD_Hex_Blob (YARA)

rule MariaDB_Temporary_MAD_Hex_Blob 

{ 

    meta: 

        description = "Detects a hexadecimal blob enclosed by double pipes in a MariaDB temporary MAD data file" 

        author = "OWN-CERT" 

        date = "21/07/2026" 

        os = "Linux" 

  

    strings: 

        $mad_header = { 

            03 01 87 01 3C FE 80 00 

            00 00 00 00 00 00 01 80 

            00 00 00 00 00 00 00 01 

            13 

        } 

  

        $hex_blob = /\|\|[0-9A-Fa-f]{64,4096}\|\|/ 

  

    condition: 

        $mad_header at 0 

        and $hex_blob 

} 

MariaDB_Temporary_MAD_Target_Admin_Account

rule MariaDB_Temporary_MAD_Target_Admin_Account 

{ 

    meta: 

        description = "Detects a hexadecimal blob related to the Wordpress administrator account, poc-vulnerability" 

        author = "OWN-CERT" 

        date = "21/07/2026" 

        os = "Linux" 

    strings: 

        $mad_header = { 

            03 01 87 01 3C FE 80 00 

            00 00 00 00 00 00 01 80 

            00 00 00 00 00 00 00 01 

            13 

        } 

  

        $target = "||313A706F632D76756C6E65726162696C6974793A" 

  

    condition: 

        $mad_header at 0 

        and $target 

} 

Indicateurs de compromission (IoCs)