Attaques WordPress et faille PHP2Shell : ce que HiveProtect a bloqué sur nos sites

Le 21 octobre 2026, deux failles critiques de PHP ont été rendues publiques sous le nom de PHP2Shell. Sur un serveur vulnérable, elles peuvent permettre de prendre la main sur le moteur qui fait tourner WordPress. Les robots n’ont pas attendu l’annonce officielle : dès le 18 octobre, nos propres sites recevaient des attaques WordPress taillées sur le modèle de cette combinaison. HiveProtect les a toutes arrêtées.

Nous protégeons nos propres sites WordPress avec HiveProtect. Nous avons donc ouvert nos journaux et fait le compte : voici la typologie des attaques WordPress que nous avons reçues, ce que HiveProtect a bloqué, et comment. Pour que nos règles restent efficaces, nous n’en publions ni les seuils ni les signatures.

Attaques WordPress : plus de 448 000 requêtes bloquées en 3 jours

Du 20 au 23 octobre, en pleine actualité PHP2Shell, nos sites protégés par HiveProtect ont bloqué plus de 448 000 requêtes. Plus de 425 000 ont été écartées avant même d’atteindre nos serveurs, par des règles de filtrage placées en amont pour les alléger. Le reste est arrivé jusqu’à nos serveurs, où HiveProtect a pris le relais.

Sur une semaine complète, du 16 au 23 octobre, HiveProtect a arrêté sur nos serveurs 46 325 requêtes, soit plus de 6 600 par jour. Il ne s’agit pas de visiteurs égarés : 36 293 venaient d’attaquants déjà bannis par HiveProtect, presque toutes refusées par le serveur web lui-même, avant même que PHP ne démarre ; 8 928 venaient d’adresses signalées par la liste partagée HiveShield ; et 1 104 étaient des attaques détectées dans la requête elle-même par le pare-feu.

Ce n’est que la partie visible. Sur un mois, nos sites ont aussi répondu « page introuvable » plus de 7 800 fois à des visiteurs extérieurs, venus de plus de 3 000 adresses IP : de vrais lecteurs tombés sur un lien périmé, mais aussi des robots qui testent des pages une à une pour repérer un site mal protégé.

Les sept familles d’attaques arrêtées par HiveProtect

En 72 heures, du 19 au 22 octobre, HiveProtect a démasqué et signalé plus de 350 adresses attaquantes sur nos sites. Le schéma ci-dessous classe leurs 403 signalements par type ; derrière ces signalements, nous distinguons sept familles d’attaques.

1. Les éclaireurs : faire l’inventaire du site

La plupart des attaques WordPress commencent par un repérage, ce que les spécialistes appellent la reconnaissance. Le robot réclame des dizaines de pages qui n’existent pas, ou des fichiers propres à telle ou telle extension, pour savoir ce qui est installé et dans quelle version.

Comment HiveProtect l’arrête : un visiteur humain ne réclame pas toute une série de pages introuvables. En octobre, nous avons ajouté à HiveProtect une règle dédiée à ce balayage. Testée sur un mois de trafic réel avant sa mise en service, elle aurait écarté 48 adresses IP, dont 29 qu’aucune autre règle n’avait encore repérées, sans toucher ni un visiteur, ni un client, ni un robot de moteur de recherche.

2. La chasse aux fichiers secrets

C’est la famille qui a déclenché le plus d’alertes : sauvegardes oubliées, fichiers de configuration, dossiers d’outils de développement, accès d’administration. Un seul fichier de ce genre laissé au mauvais endroit peut livrer les clés de la base de données.

Comment HiveProtect l’arrête : aucun visiteur légitime n’a de raison de réclamer ces fichiers sur un site WordPress. Sur la période, aucun n’a été servi, et les adresses qui les réclamaient ont été bannies dès que leur intention était établie.

3. Le recensement des comptes utilisateurs

Avant de tenter de deviner un mot de passe, il faut connaître un identifiant. En 72 heures, nous avons relevé 777 requêtes destinées à lister les comptes de nos sites. L’une des campagnes était particulièrement organisée : seize vagues successives, deux à quatre adresses IP à la fois, situées dans des pays différents et déguisées en navigateurs récents.

Comment HiveProtect l’arrête : dans cette campagne, chaque adresse a été refusée et bannie dès sa première requête visant les comptes ; ses requêtes suivantes se sont heurtées au serveur web lui-même. Résultat : aucun nom de compte obtenu, et les cinquante adresses de la campagne ont été partagées avec nos autres sites.

4. La recherche de portes dérobées

Certains robots cherchent la trace d’un piratage précédent, par exemple un fichier malveillant déposé par un autre attaquant et resté en place. Sur un site déjà compromis, ce fichier leur ouvre directement les commandes.

Comment HiveProtect l’arrête : sur un site sain, ces fichiers n’existent pas ; les demander trahit l’intention, et l’adresse est écartée avant d’aller plus loin.

5. Les tentatives de sortir du dossier du site

C’est la famille liée à l’actualité. Une faille de WordPress permettait d’obliger un site à charger un fichier situé ailleurs sur le serveur ; combinée à PHP2Shell, elle pouvait servir à exécuter du code. Depuis la mi-septembre, nous avons compté 4 220 requêtes de ce type sur nos sites, envoyées par 47 adresses. Aucune n’a été servie.

Comment HiveProtect l’arrête : une adresse web n’a pas à sortir du dossier du site pour aller chercher d’autres fichiers sur le serveur. Le 18 octobre, HiveProtect a arrêté l’attaque taillée sur le modèle de PHP2Shell dès sa première tentative, puis banni son auteur.

6. Les imposteurs

Beaucoup de robots mentent sur leur identité : ils se présentent comme un navigateur, comme un grand moteur de recherche ou comme un service d’intelligence artificielle. D’autres viennent de serveurs loués à l’heure dans des centres de données, un profil rare chez un vrai lecteur.

Comment HiveProtect l’arrête : il ne se fie pas à ce que le visiteur déclare. Il vérifie les robots qui prétendent appartenir à un grand moteur de recherche et tient compte de l’origine réelle de la connexion. Pendant la période, six de ces serveurs ont été écartés dès leur première requête.

7. Les assauts coordonnés

Certaines campagnes sont orchestrées : plusieurs adresses frappent un site au même moment, puis l’opération passe au site suivant, quelques minutes ou quelques heures plus tard, pour passer inaperçue.

Comment HiveProtect l’arrête : c’est le rôle de HiveShield, la liste partagée de HiveProtect. Une adresse prise en flagrant délit sur un site est signalée, puis refusée sur les autres sites protégés : en 7 jours, cette liste a bloqué à elle seule 8 928 requêtes sur nos serveurs.

Et les essais de mots de passe ?

Une famille est restée discrète : les essais de mots de passe. Les deux salves repérées plus tôt dans le mois, le 17 octobre, ont été refusées sans qu’aucune connexion ne réussisse.

PHP2Shell : comment HiveProtect a coupé l’attaque

Seule, la faille PHP2Shell est difficile à exploiter. La méthode la plus simple consiste à la combiner avec une faille d’inclusion de fichiers, comme celle de WordPress évoquée plus haut. C’est une attaque de ce type que nos sites ont reçue, et HiveProtect l’a coupée à trois niveaux :

• Dès la première tentative : la requête d’inclusion est refusée par le pare-feu HiveProtect, avant que WordPress ne la traite.
• Au plus près du serveur : l’attaquant est banni aussitôt. Ses requêtes suivantes sont refusées par le serveur web lui-même et n’atteignent même plus PHP : l’attaque ne peut plus aboutir.
• Sur tous les sites : son adresse est signalée à HiveShield, qui la partage avec les autres sites protégés.

Résultat : aucune de ces tentatives n’a abouti sur nos sites. C’est toute la force d’une défense en profondeur : plusieurs barrières, chacune capable d’arrêter l’attaquant.

Ce n’est pas la première fois que PHP est visé : nous avions déjà raconté comment HiveProtect a bloqué l’attaque CVE-2024-4577.

Pourquoi ces attaques ont échoué : ce que fait HiveProtect

• Il refuse tôt : plus une requête hostile est arrêtée tôt, moins elle a de chances de toucher une faille, connue ou pas encore.
• Il bannit durablement : une adresse qui a montré son intention n’a pas droit à une seconde chance, et le bannissement s’applique au plus près du serveur.
• Il partage l’information : grâce à HiveShield, ce qu’un site apprend profite rapidement à tous les autres.
• Il démasque les imposteurs : faux robots et connexions suspectes sont reconnus, quoi qu’ils déclarent.

Toutes ces protections sont détaillées dans les fonctionnalités de HiveProtect, et notre article « Les attaques WordPress ne dorment jamais » montre comment ces campagnes s’enchaînent au quotidien.

Ce que vous pouvez faire dès aujourd’hui

• Installez un pare-feu WordPress qui bannit les attaquants au lieu de seulement les ralentir, et qui partage ce qu’il apprend.
• Gardez PHP, WordPress, votre thème et vos extensions à jour, et supprimez les extensions que vous n’utilisez plus.
• Ne laissez aucune sauvegarde ni aucun fichier de configuration dans un dossier accessible depuis le web.
• Utilisez une adresse de connexion personnalisée et des mots de passe uniques.

Pour installer et configurer HiveProtect, la documentation et le centre d’aide détaillent chaque étape.

En résumé

En pleine actualité PHP2Shell, nos sites protégés par HiveProtect ont bloqué plus de 448 000 requêtes en 3 jours, et HiveProtect en a arrêté plus de 46 000 sur nos serveurs en une semaine, réparties en sept familles d’attaques. Face à PHP2Shell comme au reste, sa logique ne change pas : refuser tôt, bannir pour de bon et partager l’information.

Votre site reçoit les mêmes attaques WordPress, que vous les voyiez ou non. Découvrez les formules HiveProtect et protégez-le dès aujourd’hui.