Les sites WordPress sont attaqués juste parce qu’ils sont en ligne : 422 attaques en 7 heures
Un site WordPress n’a pas besoin de visiteurs, de contenu ni de liens entrants pour être attaqué. Il suffit qu’il existe. Le 6 septembre 2026, nous avons mis en ligne 21 Honeypots WordPress vides ; en l’espace de sept heures, ils ont essuyé 422 attaques provenant de 85 adresses IP, la première survenant 15 minutes après leur mise en ligne.
Avertissement à tous les propriétaires de sites : personne ne connaissait l'existence de ces 21 sites. Pas de lien, pas de référencement sur les moteurs de recherche, pas de visiteurs. Ils ont pourtant subi environ 20 attaques chacun en l'espace d'un après-midi, et les 21 ont tous été touchés. Votre site reçoit le même trafic dès le jour de sa mise en ligne, et non pas seulement lorsqu’il devient populaire. Protégez wp-login.php, xmlrpc.php et la REST API de votre site avant le lancement, et non après le premier incident.
Aucun des 21 domaines n’était lié à un autre, n’avait été soumis à un moteur de recherche ni mentionné où que ce soit. La seule trace publique était un certificat TLS fraîchement émis. Pour observer ce phénomène sur votre propre serveur, suivez le guide de configuration du Honeypot Server ; une instance est opérationnelle en une dizaine de minutes.
En combien de temps les pirates parviennent-ils à repérer un nouveau site WordPress ?
La flotte a été mise en service entre 12 h 30 et 12 h 45 UTC. La première détection sur un tout nouvel hôte (web00) a été enregistrée à 12 h 49 min 57 s UTC. Au cours de l’heure de 13 h 00 UTC, les 21 serveurs ont enregistré 120 attaques, ce qui a constitué la plus forte vague de la journée jusqu’à un deuxième pic de 150 attaques au cours de l’heure de 16 h 00 UTC.
Comment a-t-on pu savoir que ces serveurs existaient ? Chaque certificat émis par Let’s Encrypt est publié en quelques secondes dans les journaux publics de Certificate Transparency. Les scanners s’abonnent à ces flux de journaux et analysent chaque nouveau nom d’hôte dès son apparition. C’est sans doute ce qui s’est passé ici : aucun lien entrant, aucun signalement de plan du site, aucune requête de robot d’indexation avant l’émission du certificat, puis une analyse complète 15 minutes plus tard.
À quoi ressemblent 422 attaques sur un nouveau site WordPress ?
Tous les chiffres concernent la journée du 6 septembre 2026, de 00 h 00 à 19 h 30 UTC, sur l’ensemble des 21 serveurs. Nos propres adresses IP de surveillance sont exclues. La répartition des requêtes était la suivante : 335 GET, 80 POST, 4 HEAD et 3 PROPFIND.
| Chemin d’accès | Vues | Ce que la demande vise à obtenir |
|---|---|---|
/ | 91 | Récupération de la page d’accueil par un scanner, identifiée grâce à l’agent utilisateur et au comportement |
/?rest_route=/batch/v1 | 64 | wp2shell, exploit par lots REST CVE-2026-63030 |
/.env | 47 | Fichier d’environnement contenant les identifiants de la base de données et de l’API (plus 10 résultats sur .env.local, .env.example, .env.production) |
/xmlrpc.php | 28 | Abus via XML-RPC, tentatives de Login par appels multiples |
/author/admin/ | 23 | User Enumeration |
/wp-login.php?action=lostpassword | 22 | Abus liés à la réinitialisation du mot de passe |
/secure-vault-q4m8/ | 16 | Piège à araignées : un lien invisible pour les humains (voir ci-dessous) |
/wp-config.php.bak | 15 | Copie de sauvegarde du fichier de configuration de WordPress |
/.git/config | 11 | Dépôt Git accessible au public |
/wp-content/debug.log | 11 | Journal de débogage avec les chemins d’accès et les traces de pile |
wp2shell est la technique d’attaque la plus répandue, devant le vol de fichiers .env
La détection la plus fréquente a été celle de l’exploit REST par lots derrière wp2shell : 69 détections en sept heures, sur des hôtes existant depuis moins d’une journée. Cela place une vulnérabilité majeure révélée en juillet devant les sondes .env (40 détections ; le chemin d’accès lui-même a été sollicité 47 fois), l’exploitation de XML-RPC (27) et l’attaque par Brute Force sur wp-login (24). Nous avons détaillé la chaîne d’attaque et les Firewall Rules permettant de la bloquer dans l’article consacré à wp2shell.
En fonction des Threat Categories de ReportedIP, la journée se répartit comme suit :
- Bad Web Bot (catégorie 19) : 82 signalements
- WP REST API Abuse + WP Core Exploit (34, 37) : 58 signalements
- Port Scan + Hacking + exposition du fichier WP-Config (14, 15, 58) : 53 signalements
- Port Scan + Hacking (14, 15) : 30 signalements
- Brute Force + WP Login Brute Force (18, 31) : 24 signalements
Un scanner, 21 cibles : pourquoi la corrélation à l’échelle de la flotte est essentielle
34 des 85 adresses IP des attaquants (40 %) ont ciblé plus d’un hôte. Une adresse IP, 159.69.198.144, appartenant à une plage Hetzner, a balayé l’ensemble des 21 hôtes avec un total de 66 requêtes. Une deuxième, 157.143.67.218, a atteint 20 des 21 hôtes. L’adresse 130.12.180.117 a couvert 17 hôtes, et trois adresses issues d’une plage OVH (158.69.55.148, 158.69.117.45, 158.69.55.82) ont généré 46 résultats à elles toutes.
- 51 adresses IP ont atteint exactement un hôte
- 15 adresses IP ont atteint deux hôtes
- 7 adresses IP ont atteint trois hôtes
- 12 adresses IP ont atteint entre 4 et 21 hôtes
Un site isolé ne détecte qu’une seule sonde et ne peut pas distinguer une requête isolée d’une campagne. En revanche, vingt-et-un sites détectant la même adresse IP en l’espace de quelques minutes en sont capables. Le Confidence Score récompense cette diversité grâce à son critère de diversité des sources : une adresse signalée par plusieurs sources indépendantes grimpe plus rapidement dans le classement qu’une adresse signalée à plusieurs reprises par une seule source.
Le piège à araignées : 16 visites sur un lien invisible à l’œil nu
Chaque page d’accueil d’un Honeypot contient un lien vers /secure-vault-q4m8/ qui est masqué par display:none. Une personne naviguant sur le site ne le voit jamais. Un moteur de recherche qui analyse la page l’ignore. Le seul client qui le sollicite est un bot qui extrait tous les href liens du code HTML et les suit tous. Cela s’est produit 16 fois le premier jour, et chaque visite a été signalée avec la catégorie « honeytoken ». Ce mécanisme est décrit dans l’article consacré aux Decoy Paths.
Les agents utilisateurs le confirment. 192 requêtes comportaient une chaîne Chrome tronquée et falsifiée (Windows NT 10.0 sans le jeton Chrome), ce qui représentait le plus grand parc de scanners de la journée. 66 requêtes provenaient de curl/7.74.0, 28 d’une chaîne Android Nexus 5 (un appareil de 2015) et 5 de l9scan (leakix.net). 32 requêtes comportaient ClaudeBot/1.0, que le classificateur de bots classe parmi les agents IA plutôt que parmi les attaquants.
Contexte : un seul serveur a enregistré à lui seul 12 357 attaques
L’un des 21 serveurs hôtes, web05, fonctionnait déjà comme un « Honeypot » isolé depuis début septembre et totalise à ce jour 12 357 attaques enregistrées. Les 20 autres en sont à leur premier jour. Nous publierons à nouveau les chiffres relatifs à l’ensemble de la flotte dès qu’ils couvriront un mois complet ; les chiffres trimestriels sont disponibles dans le WordPress Attack Report.
Ce que cela implique pour votre propre site WordPress
Ces 21 « Honeypots » sont de simples interfaces WordPress hébergées sous des noms de domaine ordinaires. Rien en eux n’a attiré l’attention des scanners, si ce n’est le fait qu’ils étaient accessibles. Les 85 mêmes adresses qui les ont sondés sondent tous les autres sites WordPress qu’elles trouvent dans les journaux de certificats, y compris le vôtre. Cela a trois conséquences pour votre propre site :
- Sécurisez le site avant qu’il ne reçoive du trafic. Les attaques commencent avant même l’arrivée du premier visiteur. Le Login, le protocole XML-RPC et l’Endpoint REST pour les traitements par lots doivent être protégés dès le jour de l’installation.
- Bloquez en fonction de la réputation, et non en fonction des incidents. 40 % des adresses IP des attaquants ciblent plusieurs hôtes. Une adresse qui a déjà été signalée par d’autres sites peut être bloquée avant même d’atteindre votre formulaire de Login. C’est ce que fait ReportedIP Hive grâce aux données de la communauté.
- Whitelistez votre propre système de surveillance. Une vérification de disponibilité effectuée via curl ressemble en tous points à celle d’un scanner. Ajoutez ses adresses IP avant son exécution, sinon vous risquez d’être signalé.
Créez votre propre honeypot avec le ReportedIP Honeypot Server
Les 21 hôtes utilisent tous le ReportedIP Honeypot Server 1.3.10, une application PHP autonome qui émule une installation WordPress, Drupal ou Joomla. Elle nécessite PHP 8.2 avec pdo_sqlite et curl, ne présente aucune dépendance Composer, stocke toutes ses données dans SQLite et est fournie avec un fichier Dockerfile.
- 39 Threat Analyzers pour détecter les injections SQL, le parcours de chemins, les attaques Brute Force, le Credential Stuffing, l’exploitation abusive de XML-RPC, les failles de plugins, l’accès aux fichiers de configuration et les tentatives de création de webshells
- Honeytokens : les faux
.env,.git/configet les fuites de phpMyAdmin intègrent des identifiants « canary » spécifiques à chaque adresse IP ; toute réutilisation de ces identifiants est un signal malveillant confirmé - Piège à araignées et « tarpit » : liens cachés, chemin d’appât dans le fichier robots.txt, « tarpit » de type SQLi aveugle et faux espace d’administration « sticky » qui capture les payloads de plugins téléversés
- Envoi automatique de rapports vers l’API ReportedIP avec Rate Limiting et délai d’attente exponentiel, ainsi que des Webhooks pour votre SIEM, Slack ou AbuseIPDB
- Dashboard d’administration pour les attaques, les Payloads, les honeytokens déclenchés et les Whitelists
Pour envoyer des signalements, vous devez disposer d’une Community Access Key. Chaque compte ReportedIP en comprend une : inscrivez-vous, puis copiez la clé depuis votre Dashboard. Un détail de configuration est plus important que les autres : redirigez toutes les requêtes, y compris les fichiers dotfiles et robots.txt, vers public/index.php. Les panneaux d’hébergement géré répondent souvent à /.env par un 403 émis directement par le serveur web, ce qui empêche le piège de détection de la source de se déclencher. curl -s https://your-honeypot/.env devrait renvoyer le faux fichier, et non une page d’erreur.
Les rapports des « honeypots » sont intégrés au même pool que ceux provenant des sites protégés par Hive : le Confidence Score par adresse IP et la Dynamic Blacklist à laquelle puisent les installations Hive, fail2ban et les pare-feu.
Foire aux questions
Comment les scanners ont-ils pu trouver des noms de domaine qui n’avaient jamais été publiés ?
Grâce aux journaux de « Certificate Transparency ». Chaque certificat TLS reconnu comme fiable par le public y est consigné, et ces journaux peuvent faire l’objet de recherches en temps réel. Un nouveau nom d’hôte muni d’un certificat tout récent est visible par toute personne consultant ce flux, ce qui explique pourquoi la première requête est arrivée 15 minutes après la mise en service.
Une requête visant le fichier /.env sur mon site WordPress constitue-t-elle une attaque ?
Oui. Aucun navigateur, plugin ou moteur de recherche n’a de raison de demander ce fichier. Le 6 septembre, il s’agissait du troisième chemin d’accès le plus fréquent sur l’ensemble du parc, avec 47 requêtes, auxquelles s’ajoutent 10 pour les variantes de .env. Assurez-vous que votre serveur web ne renvoie rien d’exploitable pour ce chemin.
Le honeypot va-t-il signaler mes propres vérifications de disponibilité ?
Oui, si vous ne les ajoutez pas à la Whitelist. Ajoutez les adresses IPv4 et IPv6 de vos systèmes de surveillance et d’administration à la Whitelist lors de l’installation, avant l’exécution du premier contrôle d’état. Pour les analyseurs, un test de disponibilité basé sur curl ressemble à un scanner.