Les sondages visant le point de terminaison batch de l'API REST de WordPress ont plus que triplé sur notre infrastructure
La semaine du 26 octobre, le nombre de sources ayant demandé à notre infrastructure le point de terminaison batch de l'API REST de WordPress, porte d'entrée de la chaîne de failles wp2shell, a atteint 3.3 fois sa moyenne hebdomadaire précédente. Les scanners ont aussi demandé plus souvent des sauvegardes, des pages de débogage et des éléments internes d'applications.
291 Intercept est notre rapport hebdomadaire sur ce que les scanners automatisés ont ciblé sur notre propre infrastructure, pour que vous puissiez vérifier les mêmes points sur vos systèmes. Chaque édition porte sur une semaine terminée depuis au moins sept jours.
Le changement le plus net observé sur notre infrastructure la semaine du 26 octobre est un bond des requêtes visant une adresse WordPress précise : /wp-json/batch/v1. Environ 40 sources l'ont demandée, soit 3.3 fois sa moyenne hebdomadaire des trois semaines précédentes. C'est par ce point de terminaison que commence wp2shell, une chaîne de deux failles du cœur de WordPress qui permet à un attaquant non authentifié d'exécuter du code sur un site.
Cette hausse s'inscrit dans une semaine globalement plus chargée : environ 620 sources ont sondé notre infrastructure exposée sur Internet, 10 % de plus que la moyenne des trois semaines précédentes. WordPress est resté la cible principale, avec 66 % des sources qui s'en sont prises aux pages de connexion, à XML-RPC ou aux chemins de plugins WordPress, en hausse de 20 %. Les scanners ont aussi demandé plus souvent des éléments d'une application censés rester privés.
Qu'est-ce que wp2shell ?
/wp-json/ est la racine de l'API REST de WordPress, et /wp-json/batch/v1 son processeur de lots, qui traite un ensemble de requêtes API en une seule fois. Selon Rapid7, wp2shell combine deux failles. CVE-2026-63030 est une faille logique dans ce processeur de lots, et CVE-2026-60137 une injection SQL dans le point de terminaison des articles. Enchaînées, elles permettent à une personne sans compte d'exécuter du code sur WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1.
La faille a été divulguée le 17 juillet 2026, et Rapid7 indique que la CISA l'a ajoutée à son catalogue Known Exploited Vulnerabilities le 21 juillet. Les versions corrigées sont 6.9.5, 7.0.2 et 7.1 Beta 2.
Pourquoi rechercher une faille déjà corrigée ? Les scanners n'ont pas besoin que tous les sites soient vulnérables, il leur suffit que certains le soient. Une requête ne leur coûte presque rien, et tout site encore sur une version concernée mérite qu'ils y reviennent.
Le volet habituel du scan WordPress
Une boîte à outils coordonnée d'environ 20 sources, réparties dans quelques pays, a parcouru la même liste d'une dizaine de chemins. Elle a demandé le même fichier sous de nombreux noms de dossier, par exemple /wp/wp-includes/wlwmanifest.xml, /shop/wp-includes/wlwmanifest.xml et /wordpress/wp-includes/wlwmanifest.xml, ainsi que /xmlrpc.php.
wlwmanifest.xml est le manifeste Windows Live Writer présent dans les installations WordPress par défaut, et le demander sous des noms de dossier courants est une façon de repérer les sites WordPress avant de tenter des exploits visant des plugins ou des thèmes. XML-RPC vient ensuite : des chercheurs ont découvert en 2015 que sa méthode system.multicall permet à un attaquant de tester des centaines de mots de passe en une seule requête.
Restes oubliés et rouages internes
Par rapport aux trois semaines précédentes, le nombre de sources à la recherche de fichiers de sauvegarde et de dumps a augmenté de 73 %, celui des sources visant les rouages internes des applications, comme l'actuator de Spring Boot, de 63 %, et celui des sources demandant des pages de diagnostic comme /phpinfo.php et /info.php de 52 %. Comme le nombre total de sources a lui aussi augmenté, leurs parts ont moins bougé : les pages de diagnostic sont passées de 15 % de l'ensemble des sources en moyenne à 21 %. Le graphique ci-dessous présente six des catégories de la semaine, chacune avec sa part de sources cette semaine comparée à sa moyenne des trois semaines précédentes.
Part de l'ensemble des sources distinctes ayant visé chaque cible, en pourcentage. Une source pouvant viser plusieurs cibles, le total des parts dépasse 100 %.
| Cette semaine | Moyenne des 3 semaines précédentes | |
|---|---|---|
| Sauvegardes et exports de bases de données | 12 % | 9 % |
| Points d'accès de gestion applicative | 13 % | 9 % |
| Pages de débogage et de diagnostic | 21 % | 15 % |
| Pages de connexion et fichiers WordPress | 66 % | 61 % |
| Code source exposé (Git, SVN) | 29 % | 24 % |
| Fichiers de secrets et de configuration | 33 % | 33 % |
/actuator/env a attiré environ 40 sources, soit 2.4 fois sa moyenne précédente. Sous Spring Boot, ce point de terminaison affiche les propriétés de configuration de l'application. La documentation de Spring précise que seul health est accessible par HTTP par défaut et que les valeurs d'env sont masquées par défaut, mais lorsque des développeurs l'exposent sans en restreindre l'accès, il peut divulguer des identifiants, des clés d'API et des paramètres internes. /wp-config.php.bak, une sauvegarde oubliée de la configuration WordPress, a doublé pour atteindre environ 40 sources.
Une deuxième boîte à outils d'environ 20 sources a combiné ces centres d'intérêt en un seul balayage : /.env, /.git/config, /info.php, /config.json, /server-status et /debug/default/view. Ce dernier chemin appartient au débogueur de Yii 2, qui affiche les données de session, les variables d'environnement et les requêtes de base de données. Le guide de Yii indique qu'il ne fonctionne normalement qu'en localhost, mais CVE-2026-103475, divulguée le 30 septembre, concerne yii2-starter-kit jusqu'à la version 4.2.0, dont la configuration par défaut l'ouvre à toutes les adresses IP.
Suite de la semaine dernière
Notre dernière édition relevait davantage de scanners à la recherche de fichiers .env dans des sous-dossiers. La tendance s'est poursuivie. /v2/.env et /old/.env ont chacun attiré environ 60 sources, à peu près le double de leur moyenne précédente, /production/.env en a attiré 50 et /storage/.env 40. Au total, 200 sources ont ciblé des fichiers de secrets et de configuration, en hausse de 16 %, soit à peu près au rythme de la hausse globale des sources : leur part est donc restée stable à 33 %. Pour donner un ordre de grandeur, des chercheurs ont signalé en février 12,088,677 adresses IP servant des fichiers de type .env accessibles publiquement.
Le sondage Git, qui faisait la une de notre dernière édition, a reculé en part mais reste au-dessus de son niveau antérieur. Au total, 170 sources ont cherché des dépôts de code source, 20 % de plus que la moyenne sur trois semaines, même si leur part dans l'ensemble des sources est passée de 37 % à 29 %.
D'où venaient les requêtes
Plus de la moitié des sources (55 %) provenaient de réseaux cloud et d'hébergement, DigitalOcean et Google Cloud en représentant chacun 20 %, et 85 % de l'ensemble des sources ne sont apparues qu'un seul jour. La plupart cherchaient aussi à passer pour des humains : 82 % envoyaient des chaînes User-Agent imitant des navigateurs ordinaires, mais 85 % se comportaient comme des outils automatisés, si bien que le déguisement reste bien mince.
Ce qui s'est calmé
Les requêtes visant /wp-content/plugins/hellopress/wp_filemanager.php, qui attiraient en moyenne environ 20 sources par semaine, sont presque tombées à zéro, en baisse de 79 %. Il est trop tôt pour dire si les scanners sont passés à autre chose. Les fichiers de clés cloud comme /service-account.json sont restés à peu près stables, à 70 sources.
Que faire
- Vérifiez votre version de WordPress. Si elle est comprise entre 6.9.0 et 6.9.4 ou entre 7.0.0 et 7.0.1, passez dès maintenant à 6.9.5 ou 7.0.2.
- Sortez complètement les fichiers .env du dossier public, y compris dans les anciennes versions et les sous-dossiers versionnés. L'emplacement sûr se trouve un niveau au-dessus de la racine web.
- Supprimez les sauvegardes et les dumps comme
/database.sqlou/wp-config.php.bakde tout emplacement accessible depuis un navigateur. - Verrouillez les rouages internes. Restreignez les endpoints actuator de Spring Boot et laissez le masquage d'env activé, supprimez les pages de test phpinfo et limitez le débogueur Yii à localhost.
- Désactivez XML-RPC si rien sur votre site n'en a besoin.
À propos de ces observations
Ce rapport est produit par 291 Heat Seeker One, le système de surveillance de sécurité de 291 Group, qui fonctionne sur 291 Crossband, notre plateforme propriétaire d'opérations de sécurité. Il ne couvre que le trafic à destination de l'infrastructure de 291 Group exposée sur Internet.
Les chiffres sont arrondis, les parts et les variations sont mesurées en nombre de sources distinctes et non en nombre de requêtes, et seuls les schémas observés depuis au moins 20 sources distinctes sont retenus. Les pays correspondent à l'emplacement des serveurs des sources, pas nécessairement à celui des personnes qui les exploitent. Les types de réseau sont déterminés d'après l'opérateur de chaque réseau ; seuls les grands fournisseurs bien connus sont nommés.