wp2shell, un faux Chrome et un botnet en trench-coat : ce que mes propres logs d'accès ont balancé

🌐 Aussi en: English · Deutsch · Español

Il y a quelques jours, « wp2shell » a fait le tour du Web – une chaîne RCE sans authentification dans WordPress, bricolée à partir d’une injection SQL (CVE-2026-60137) et d’un contournement de validation dans l’endpoint REST batch (CVE-2026-63030). 🩸 Tout WordPress ≥6.8 était exposé, et upstream a fini par corriger le tout dans 7.0.2. Pendant quelques jours à se ronger les ongles, ce blog même a tourné avec un blocage nginx d’urgence sur /wp-json/batch/v1, parce que l’image Docker corrigée refusait tout simplement d’exister. Grand classique. 🙃 Alors évidemment, une fois l’incendie éteint, j’ai fait ce que fait tout nerd du homelab qui se respecte à 2 heures du matin : je suis parti en spéléologie dans mes propres logs d’ingress. 🕵️‍♂️ Verdict : Internet se fiche bien que vous ayez patché. Internet continue de frapper à la porte.

Table of Contents

🔍 Les pièces à conviction du log d’accès

Au premier passage dans les logs, je pensais avoir une jolie petite poignée de requêtes. Puis j’y suis retourné avec un meilleur grep (il se trouve que les lignes brutes du log d’accès de nginx ne répètent pas le nom d’hôte, donc mon premier filtre par domaine avalait discrètement de vraies requêtes – même les nerds du homelab ont leurs mauvais jours 🤦) et j’ai découvert qu’il y en avait bien plus qu’une poignée.

🌊 Le déluge d’ouverture, 18–19 juillet – le jour de la publication de la CVE, mes logs se sont illuminés de dizaines de requêtes, presque toutes venant du même User-Agent merveilleusement peu discret, wp2shell.com scanner, qui tournait sur une petite armée d’IP derrière Cloudflare et obtenait le plus souvent un 207 (traité, avant la parade). En gros, les chercheurs en sécurité d’Internet (ou les « chercheurs » 🧐) faisant un tour d’honneur synchronisé à la seconde où la faille est devenue publique.
😂 Rebelote avec le même UA de scanner le 20 juillet : 403, bloqué par ma règle d’urgence. 💪 Puis à nouveau le 21 juillet, alors que la règle était désactivée un instant : 207, passé comme une lettre à la poste. 🎯 (La CVE elle-même était déjà corrigée à ce moment-là, donc – un pétard mouillé pour tout le monde.)
🕵️ Mon préféré : une machine EC2 chez AWS Tokyo (ec2-*.ap-northeast-1.compute.amazonaws.com, oui, j’ai fait la résolution DNS inverse, oui, je me suis senti très malin), portant un faux User-Agent Chrome comme un déguisement d’Halloween bon marché. 🎭 Elle a demandé /, a attendu exactement une (1) seconde, puis est allée droit sur l’endpoint de l’exploit. Pas de CSS. Pas de JS. Pas de favicon. Aucun être humain ne navigue comme ça – un vrai Chrome charge l’équivalent d’un petit roman en ressources à chaque page vue. Bien essayé, robot. 🤖
🆕 Mise à jour pendant que j’écrivais encore cet article : un petit nouveau est arrivé de Google Cloud (*.bc.googleusercontent.com), deux requêtes, à une seconde d’intervalle, toutes deux en 207 – et celui-ci a même pris la peine de s’étiqueter avec son propre paramètre de suivi, &_w2s=347b2f52 / &_w2s=b58fad1b. L’outil de scan de quelqu’un numérote apparemment ses propres tentatives désormais. Quelle efficacité ! 📊 Troisième grand fournisseur cloud repéré jusqu’ici (derrière Cloudflare, AWS, maintenant GCP) – ce truc a des amis partout.

🤔 D’accord, mais qui fait ça, au juste ?

Bonne question, et elle mérite d’être détaillée pour tous ceux qui ne contemplent pas des logs serveur pour le plaisir : tous ceux qui fouinent autour d’une vulnérabilité connue ne sont pas des criminels. Il y a un vrai spectre ici, et les indices comptent. 🔬

😇 Côté bonne foi : les sociétés de recherche en sécurité et les services de scan (pensez à Shodan, Censys, aux projets dans le style de GreyNoise) balayent en permanence Internet à la recherche de CVE connues – parfois pour alimenter des flux publics de threat intelligence, parfois pour que les propriétaires de sites concernés puissent y chercher leur propre site et se dire « oh non ». Un outil qui s’appelle littéralement wp2shell.com scanner dans son propre User-Agent correspond bien à ce profil : il n’a aucune raison de se cacher, et annoncer haut et fort qui l’on est, c’est exactement ce que font les scanners légitimes (et souvent ce qu’attendent les règles de divulgation responsable).
😈 Côté mauvaise foi : des attaquants qui lancent exactement le même genre de vérification, sauf que le but n’est pas « prévenir quelqu’un », mais « trouver une porte par laquelle je peux encore entrer » – pour déposer un webshell, un injecteur de spam, un cryptomineur, ou simplement ajouter la machine à un botnet. Ce sont eux qui ont tout intérêt à se fondre dans la masse.

C’est exactement pour ça que je reviens sans cesse aux cas avec un faux User-Agent Chrome (celui d’AWS Tokyo, celui de GCP) comme étant les plus intéressants : un scanner honnête n’a pas besoin de se déguiser en navigateur d’un visiteur ordinaire. Quelque chose qui se fait passer pour une personne, précisément pour ne pas ressembler à un scanner, a une raison de se cacher – et « j’ai de bonnes intentions » n’en est généralement pas une. 🎭 Donc, résumé honnête pour les profanes : il s’agit presque certainement d’un mélange des deux, et je ne peux pas prouver une intention à partir d’un simple log d’accès – une réponse 207 me dit que l’endpoint a répondu, pas ce que quelqu’un essayait d’en faire. Mais le scanner qui s’annonce lui-même est probablement plus proche du « bruit de fond d’Internet / outillage de sécurité », tandis que les déguisés sont ce qui se rapproche le plus de « quelqu’un qui espère vraiment entrer ». Comme le bug WordPress sous-jacent est corrigé de toute façon, aucun des deux camps n’est allé bien loin ici – mais le schéma lui-même vaut la peine d’être connu. 🛡️ En toute transparence, pour les nerds qui tiennent les comptes à la maison : mes propres tests curl – ceux que j’ai lancés pour vérifier que le blocage fonctionnait vraiment – figurent dans ce même fichier de log, à plusieurs reprises, parce qu’apparemment je ne pouvais pas me contenter de vérifier une seule fois. 😅 Donc techniquement, je suis moi aussi « une adresse IP qui sonde l’endpoint vulnérable ». Coupable, Votre Honneur. 👨‍⚖️ Et ce n’est pas juste ma paranoïa, d’ailleurs : Golem.de a aussi couvert exactement cette vague de tentatives d’exploitation en cours – « Lücken in WordPress: Laufende Schadcode-Attacken gefährden Millionen von Websites » – ce n’est donc pas une théorie du complot isolée d’un blog de homelab. 📰 C’est un phénomène qui touche vraiment tout Internet.

🕸️ Manche bonus : les scrapers en trench-coat

Pendant que j’étais au fond de la mine de logs à chercher wp2shell, je suis tombé sur quelque chose de bien plus gros et, honnêtement, plus intéressant : 765 adresses IP différentes, réparties sur au moins 530 blocs réseau /16 distincts (donc : partout, pas un seul datacenter), chacune se présentant pour faire exactement une ou deux requêtes avant de disparaître à jamais. 👻 Chacune d’entre elles présentait un UA de navigateur de bureau parfaitement normal – Chrome ou Edge, Windows ou Mac, la totale. Rien qui vous sauterait aux yeux. Mais alignez-les toutes et le masque tombe immédiatement : elles ne visitaient que mes quelque 31 pages d’archives par étiquette, catégorie et date (/tag/ansible, /category/devsecops, /2025/05, etc.), en parcourant méthodiquement la liste – et pas une seule n’a ensuite récupéré le moindre fichier CSS, fichier JS ou image. 🖼️🚫 Un vrai onglet Chrome charge deux douzaines de ressources par page vue sans que vous leviez le petit doigt. Celles-ci n’en ont chargé aucune. C’est la signature d’un botnet de scraping via des proxys résidentiels : au lieu de marteler le site depuis une seule IP (ce qui vous vaut d’être limité ou banni en quatre secondes environ), on loue quelques centaines de milliers de vraies IP résidentielles et on envoie depuis chacune exactement une requête polie, « promis, je suis un vrai humain ». La mort par mille coupures de papier, sauf que les coupures sont impossibles à distinguer de vrais lecteurs, à moins de prendre assez de recul pour voir le schéma. 🔎 Vu la cible (parcourir systématiquement chaque page d’archives, c’est-à-dire l’index complet du contenu du site, pas seulement la page d’accueil), je parie sur du scraping de contenu à grande échelle – du bon vieux vol de contenu pour le SEO, ou quelqu’un qui constitue un jeu de données d’entraînement pour une IA. Quoi qu’il en soit : 765 « visiteurs » qui ont lu zéro mot et chargé zéro police n’ont jamais été des visiteurs. 🤖🕶️

🎬 À retenir

La faille elle-même est colmatée depuis un moment (ce blog tourne en 7.0.2 depuis le premier jour où c’était possible). Mais le scan d’une CVE fraîchement annoncée ne s’arrête pas juste parce que quelqu’un, quelque part, a livré un correctif. 📡 Les bots de scan ne lisent pas les changelogs. Si vous faites tourner un WordPress exposé au public, ce genre de trafic n’est que du bruit de fond – une bonne excuse pour jeter vraiment un œil à vos logs d’accès de temps en temps, au lieu de supposer que « patché == terminé ». 🛡️