Les sites WordPress sont attaqués simplement parce qu’ils sont en ligne : 356 attaques en 7 heures
Un site WordPress n’a besoin ni de visiteurs, ni de contenu, ni de backlinks pour être attaqué. Le 6 septembre 2026, 21 nouveaux honeypots WordPress dont personne ne connaissait l’existence ont subi 356 attaques de 84 adresses IP en sept heures, et la première attaque est arrivée 15 minutes après la mise en ligne.
Avertissement pour tous les propriétaires de sites : personne ne savait que ces 21 sites existaient. Aucun lien, aucun moteur de recherche, aucun visiteur. Les 21 ont pourtant tous été attaqués, environ 17 fois chacun en un après-midi. Votre site reçoit le même trafic dès le jour de sa mise en ligne. Protégez wp-login.php, xmlrpc.php et l’API REST le jour de l’installation.
Aucun des 21 domaines n’était lié, soumis à un moteur de recherche ou mentionné où que ce soit. La seule trace publique était un certificat TLS tout juste émis. Pour observer le même trafic sur votre propre serveur, suivez le guide du Honeypot Server.
En combien de temps les attaquants trouvent-ils un nouveau site WordPress ?
Les attaquants ont trouvé les nouveaux sites en 15 minutes. La flotte a été mise en ligne entre 12:30 et 12:45 UTC, et la première détection sur l’un des nouveaux hôtes a été enregistrée à 12:49:57 UTC. Une première vague a suivi dans l’heure de 13:00 UTC. L’heure la plus chargée de la journée a été celle de 16:00 UTC, avec 150 attaques.
Comment quelqu’un pouvait-il savoir que ces hôtes existaient ? Chaque certificat émis par Let’s Encrypt est publié en quelques secondes dans les journaux Certificate Transparency publics. Les scanners s’abonnent à ces flux et sondent chaque nouveau nom d’hôte dès qu’il apparaît. C’est la voie la plus probable ici : aucun backlink, aucun ping de sitemap, aucune visite de robot avant l’émission du certificat, puis un scan complet 15 minutes plus tard.
À quoi ressemblent 356 attaques sur un nouveau site WordPress ?
Tous les chiffres portent sur le 6 septembre 2026, de 00:00 à 19:30 UTC, sur les 21 hôtes. Vingt hôtes ont été mis en ligne à midi ; un autre tournait depuis des mois et a rejoint la flotte ce jour-là. Les IP de notre propre monitoring et de notre installation sont exclues.
| Chemin | Requêtes | Ce que vise la requête |
|---|---|---|
/?rest_route=/batch/v1 | 64 | Exploit REST batch wp2shell (CVE-2026-63030) |
/xmlrpc.php | 28 | Abus de XML-RPC et tentatives de connexion multicall |
/author/admin/ | 23 | Énumération des utilisateurs |
/wp-login.php?action=lostpassword | 22 | Abus de la réinitialisation du mot de passe |
/wp-config.php.bak | 15 | Copie de sauvegarde de la configuration WordPress |
/.git/config | 11 | Dépôt Git exposé |
/wp-content/debug.log | 11 | Journal de débogage avec chemins et traces d’appel |
Le fichier d’environnement /.env a été demandé plus de 40 fois, et trois variantes (.env.local, .env.example, .env.production) ont reçu 10 requêtes de plus. Les chiffres proviennent des journaux des honeypots eux-mêmes. La base de données centrale de ReportedIP présente la même journée comme 116 signalements de 76 adresses, car les requêtes répétées d’une même adresse dans un court intervalle sont regroupées en un seul signalement.
Pour comparaison : notre premier honeypot signale depuis fin février 2026 et avait envoyé 36 206 signalements au moment de rejoindre la flotte. Les chiffres trimestriels de tout le réseau figurent dans le rapport sur les attaques WordPress.
Pourquoi wp2shell est-il l’attaque la plus fréquente sur les nouveaux sites WordPress ?
L’exploit REST batch derrière wp2shell a été la détection la plus fréquente : 69 détections en sept heures, sur des hôtes qui existaient depuis moins d’une journée. WordPress a corrigé la faille le 17 juillet 2026, et les scanners l’essaient malgré tout sur chaque nouveau site qu’ils trouvent. Elle arrive devant la recherche classique de .env, l’abus de XML-RPC (27 détections) et la force brute sur wp-login (24). La chaîne d’attaque et les règles de pare-feu qui la bloquent sont décrites dans l’article sur wp2shell.
Rapportée aux catégories de menaces de ReportedIP, la journée se répartit ainsi :
- WP REST API Abuse + WP Core Exploit (34, 37) : 58 signalements
- Port Scan + Hacking + WP Config Exposure (14, 15, 58) : 53 signalements
- Port Scan + Hacking (14, 15) : 30 signalements
- Brute-Force + WP Login Brute Force (18, 31) : 24 signalements
- Bad Web Bot (catégorie 19) : scanners reconnus à leur user agent
Combien de sites un seul scanner atteint-il ?
33 des 84 IP attaquantes (39 pour cent) ont touché plus d’un hôte. Une adresse, 157.143.67.218, a atteint 20 des 21 hôtes. 130.12.180.117 a couvert 17 hôtes, et trois adresses d’une même plage OVH (158.69.55.148, 158.69.117.45, 158.69.55.82) ont totalisé 46 requêtes.
- 51 IP ont touché exactement un hôte
- 15 IP ont touché deux hôtes
- 7 IP ont touché trois hôtes
- 11 IP ont touché entre 4 et 20 hôtes
Un site isolé voit une sonde et ne peut pas distinguer une requête égarée d’une campagne. Plusieurs sites qui voient la même adresse en quelques minutes le peuvent. Sur l’ensemble du réseau, le Confidence Score récompense précisément cela : une adresse signalée par plusieurs sources indépendantes monte plus vite qu’une adresse signalée de nombreuses fois par une seule source.
Comment un spider trap démasque-t-il les robots de scan ?
Un spider trap est une adresse appât qu’une personne ne voit jamais et qu’un robot respectueux ne demande jamais. Seul un bot qui extrait tous les liens du HTML et les suit tous y arrive. Le premier jour, c’est arrivé 16 fois, et chaque requête a été signalée avec la catégorie Spider Trap. Hive applique le même principe aux sites en production avec des chemins leurres.
Les user agents confirment le tableau. 192 requêtes portaient une chaîne Chrome falsifiée et tronquée (Windows NT 10.0 sans le jeton Chrome), la plus grande flotte de scanners de la journée. 28 venaient d’une chaîne Android Nexus 5 (un smartphone de 2013), 5 de l9scan (leakix.net). 32 requêtes portaient ClaudeBot/1.0, un robot d’IA qui a suivi des liens vers xmlrpc.php et la page de connexion et a déclenché les mêmes analyseurs qu’un scanner.
Qu’est-ce que cela signifie pour votre propre site WordPress ?
Les 21 honeypots sont des frontaux WordPress ordinaires derrière des domaines ordinaires. Rien en eux n’a attiré les scanners, à part le fait d’être joignables. Les scanners qui lisent les journaux de certificats traitent votre site de la même façon. Trois conséquences :
- Sécurisez le site avant qu’il ait du trafic. Les attaques commencent avant l’arrivée du premier visiteur. La connexion, XML-RPC et le point de terminaison REST batch ont besoin d’une protection dès le jour de l’installation.
- Bloquez les attaquants connus par leur réputation. 39 pour cent des IP attaquantes ont touché plusieurs hôtes. Une adresse que d’autres sites ont déjà signalée peut être bloquée avant d’atteindre votre formulaire de connexion. ReportedIP Hive le fait avec les données de la communauté.
- Mettez votre propre monitoring en liste blanche. Un contrôle de disponibilité avec curl ressemble exactement à un scanner. Ajoutez ses IP avant qu’il ne tourne, sinon vous vous signalez vous-même.
Comment exploiter votre propre honeypot WordPress ?
Les 21 hôtes utilisent le ReportedIP Honeypot Server, en version 1.3.10 le jour de la mesure ; la version actuelle est la 1.4.1. C’est une application PHP autonome qui imite une installation WordPress, Drupal ou Joomla. Il lui faut PHP 8.2 avec pdo_sqlite et curl, il n’a aucune dépendance Composer, stocke tout dans SQLite et est livré avec un Dockerfile. Le code source est consultable sous Business Source License 1.1 : l’usage en production est autorisé tant que vous ne le vendez pas et ne l’exploitez pas comme service hébergé pour des tiers, et la licence passe à Apache 2.0 le 1er mars 2030.
- 40 Threat Analyzers pour l’injection SQL, le path traversal, la force brute, le credential stuffing, l’abus de XML-RPC, les exploits de plugins, l’accès aux fichiers de configuration, les sondes de webshell et l’exploit REST batch wp2shell
- Honeytokens : de fausses fuites de configuration contiennent des identifiants canari propres à chaque IP ; qui en réutilise un est malveillant de façon avérée
- Pièges : un spider trap, un tarpit pour les injections SQL à l’aveugle et une fausse zone d’administration qui enregistre les charges utiles de plugins envoyées
- Signalement automatique à l’API de ReportedIP avec limitation de débit et backoff exponentiel, plus des webhooks vers votre SIEM, Slack ou AbuseIPDB
- Tableau de bord d’administration pour les attaques, les charges utiles, les honeytokens déclenchés et les listes blanches
Le signalement nécessite une Community Access Key. Chaque compte ReportedIP en contient une : créez un compte gratuit, puis copiez la clé depuis votre Dashboard. Un détail de configuration compte plus que tous les autres : faites passer chaque requête, y compris les fichiers cachés et robots.txt, par public/index.php. Les panneaux d’hébergement géré répondent souvent à /.env par un 403 du serveur web, et les pièges ne se déclenchent alors jamais.
Les signalements des honeypots rejoignent le même ensemble de données que ceux des sites protégés par Hive : le Confidence Score par IP et la Dynamic Blacklist que récupèrent les installations Hive, fail2ban et les pare-feu.
Questions fréquentes
Comment des scanners ont-ils trouvé des domaines jamais publiés ?
Les scanners les ont très probablement trouvés grâce aux journaux Certificate Transparency. Chaque certificat TLS de confiance publique y est enregistré, et ces journaux se lisent en temps réel. Un nouveau nom d’hôte avec un certificat récent est visible pour quiconque surveille le flux, ce qui explique la première sonde 15 minutes après la mise en ligne.
Une requête vers /.env sur mon site WordPress est-elle une attaque ?
Une requête vers /.env est toujours hostile. Aucun navigateur, plugin ou moteur de recherche n’a de raison de demander ce fichier. Le 6 septembre 2026, il a été demandé plus de 40 fois sur la flotte, plus 10 fois sous forme de variantes. Veillez à ce que votre serveur web ne renvoie rien d’exploitable.
Le honeypot va-t-il signaler mes propres contrôles de disponibilité ?
Le honeypot signale vos contrôles de disponibilité tant que vous ne les mettez pas en liste blanche. Ajoutez les adresses IPv4 et IPv6 de vos systèmes de monitoring et d’administration à la liste blanche pendant l’installation, avant le premier contrôle. Une sonde de disponibilité basée sur curl ressemble à un scanner pour les analyseurs et est signalée comme tel.