down.php, .wp-log.php, .bd.php : ces fichiers signifient que votre WordPress est backdooré

Vous avez repéré un fichier down.php, .bd.php ou .wp-log.php quelque part dans votre installation WordPress, souvent dans wp-content/uploads/ ou un répertoire de cache. Vous l'avez cherché sur Google parce qu'il ne vous dit rien. Voici la réponse directe : ce fichier est un webshell, votre site est compromis, et l'accès à votre serveur est peut-être déjà en vente. On vous explique ce que c'est, d'où ça vient, et surtout pourquoi le supprimer ne règle rien.

Ces noms de fichiers sont documentés publiquement

En juin 2026, les chercheurs de SOCRadar ont découvert un serveur d'attaque laissé ouvert par ses opérateurs. À l'intérieur : les outils, les logs et les listes de cibles d'une opération baptisée WP-SHELLSTORM. Les fichiers déposés sur les sites compromis y sont nommés noir sur blanc :

• down.php : le webshell principal, dérivé du webshell chinois open source BestShell, protégé par quatre couches d'obfuscation.
• .bd.php et .wp-log.php : des portes dérobées secondaires, préfixées d'un point pour être invisibles avec un simple ls ou dans certains gestionnaires de fichiers.
• .brq-*.php : une famille de fichiers au préfixe variable, même logique.

L'échelle donne le vertige : les listes de cibles contenaient 1,4 million de domaines, et les chercheurs de Ctrl-Alt-Intel ont validé 25 195 compromissions effectives (SOCRadar comptait de son côté plus de 5 700 webshells encore actifs au moment de l'analyse). Les opérateurs, vraisemblablement sinophones et motivés financièrement, utilisaient le moteur de recherche FOFA pour constituer leurs listes et des scanners automatisés pour exploiter en chaîne.

Comment ils sont entrés chez vous

WP-SHELLSTORM n'exploite pas une faille unique mais un portefeuille de vulnérabilités connues. Côté WordPress, la principale est CVE-2026-3844 dans le plugin de cache Breeze : plus de 45 000 sites visés, plus de 17 000 effectivement backdoorés. D'autres CVE de plugins et de CMS complètent l'arsenal, dont une faille critique de l'éditeur JCE côté Joomla. Et depuis fin juillet, la faille WP2Shell dans le cœur de WordPress offre à tous les acteurs du même genre une porte d'entrée encore plus large.

Le point important : ces groupes ne s'intéressent pas à vous spécifiquement. Votre site est une ligne dans une liste de 1,4 million. L'exploitation est automatisée de bout en bout, du scan initial au dépôt du webshell.

Pourquoi supprimer le fichier ne suffit pas

C'est le réflexe naturel : rm down.php, et on n'en parle plus. Trois raisons font que c'est une erreur :

• L'accès est une marchandise. WP-SHELLSTORM est ce que les analystes appellent un courtier d'accès : le groupe casse les sites en masse, puis revend l'accès à d'autres criminels (spam SEO, phishing, skimmers de carte bancaire). Plusieurs acteurs peuvent donc déjà détenir une clé de chez vous, chacun avec sa propre porte.
• Les portes dérobées vont par grappes. Un webshell visible en cache souvent un second, plus discret : compte administrateur créé en base, tâche cron qui retélécharge la charge, fichier légitime de plugin modifié de quelques lignes.
• La faille d'origine est peut-être toujours ouverte. Si vous supprimez le webshell sans patcher le plugin vulnérable qui a servi d'entrée, le prochain passage du scanner vous réinfecte.

Comment chercher les autres portes dérobées

Commencez par lister tous les fichiers PHP là où il ne devrait pas y en avoir, fichiers cachés compris :

find wp-content/uploads wp-content/cache -type f -name "*.php"
find . -type f -name ".*.php"

Puis cherchez les motifs d'obfuscation classiques dans le reste du code :

grep -rn --include="*.php" -E "eval\(|base64_decode|gzinflate|str_rot13" wp-content/ | grep -v "wp-content/plugins-connus"

Attention aux faux positifs : certains plugins légitimes utilisent base64_decode. Le signal fort, c'est la combinaison de plusieurs fonctions d'obfuscation dans un fichier récent, court, au nom générique. Ne vous fiez pas aveuglément aux dates de modification : les attaquants savent les antidater.

Complétez avec la vérification des comptes administrateurs et des tâches cron, détaillée dans notre checklist de nettoyage post-WP2Shell (les 6 vérifications valent pour toutes les compromissions, pas seulement WP2Shell).

Le plan de sortie

1. Conservez une copie de l'état infecté (fichiers + base) à des fins d'analyse, séparée de vos sauvegardes.
2. Patchez la porte d'entrée : mettez à jour le cœur, tous les plugins (Breeze en tête si vous l'utilisez) et les thèmes.
3. Supprimez tous les webshells et portes dérobées identifiés en une seule session, pas au fil de l'eau.
4. Réinitialisez tous les mots de passe (WordPress, FTP/SSH, base de données) et régénérez les salts.
5. Surveillez les répertoires sensibles pendant 30 jours : toute réapparition de fichier PHP signifie qu'une porte a été manquée.

La méthode complète, y compris la sortie de blacklist Google si votre site a été marqué comme dangereux, est dans notre guide de nettoyage d'un WordPress piraté. Et si vous voulez une prise en main immédiate, notre service de suppression de malware traite exactement ce cas : cartographie de l'infection, nettoyage en une passe, hardening et monitoring 30 jours.

FAQ

Un fichier down.php est-il forcément malveillant ?

Non, le nom seul ne suffit pas : un développeur a pu créer un fichier légitime portant ce nom. Mais un down.php que personne dans votre équipe ne revendique, placé dans un répertoire d'upload ou de cache, et contenant du code obfusqué, correspond exactement à la signature WP-SHELLSTORM. Dans le doute, traitez-le comme malveillant et faites-le analyser.

J'ai supprimé le fichier il y a des semaines et rien ne s'est passé. C'est réglé ?

Pas nécessairement. Un accès backdooré peut rester dormant des mois avant d'être revendu ou utilisé. L'absence de symptôme visible ne prouve pas l'absence de porte dérobée : seule une vérification complète (fichiers, base, comptes, cron) le peut.

Comment savoir depuis quand le site est compromis ?

Croisez les dates de première apparition du fichier dans vos sauvegardes successives avec vos logs d'accès serveur : la première requête POST vers le webshell marque le début de l'exploitation active. Vos sauvegardes sont votre meilleure chronologie, gardez-les.

Mon antivirus et le scan de mon hébergeur ne détectent rien.

C'est cohérent avec ce que décrivent les chercheurs : down.php est protégé par quatre couches d'obfuscation précisément pour échapper aux signatures. Les scanners détectent les webshells connus sous leur forme connue, pas leurs variantes fraîchement réobfusquées.

Sources primaires

• The Hacker News, « Exposed Hacker Server Reveals WP-SHELLSTORM Backdooring Thousands of WordPress Sites ».
• SOCRadar, analyse de l'infrastructure WP-SHELLSTORM (publication du 9 juillet 2026, relayée par The Hacker News ci-dessus).
• Field Effect, « WordPress wp2shell attacks escalate following public PoC release ».