Les infections WordPress classiques sont déjà pénibles… mais il existe une catégorie bien plus dangereuse : les malwares persistants, capables de recréer automatiquement les fichiers supprimés, de contourner les protections, et même de tourner en tâche de fond comme un service système.
C’est exactement ce qui m’est arrivé.
Voici le récit complet, les symptômes, le diagnostic, et la méthode qui m’a permis de reprendre le contrôle du serveur.
Symptômes : des fichiers infectés qui reviennent en boucle
Tout a commencé par des fichiers suspects dans la racine du site :
- un
.htaccessmodifié - un
index.phpinfecté - un dossier au nom aléatoire :
65705 - un autre dossier étrange dans
wp-content:x06f239
Je les supprimais…
Ils revenaient immédiatement.
Même en supprimant les fichiers PHP dans uploads, comme :
wp-content/uploads/system_cache.php
…le fichier se recréait instantanément.
C’était le signe d’une backdoor active, pas d’un simple script dormant.
Étape 1 — Vérifier les permissions et l’espace disque
Avant d’accuser WordPress, j’ai vérifié :
- les permissions Unix
- les propriétaires des fichiers
- l’espace disque
- l’état du filesystem
Tout était normal.
Donc le problème ne venait ni du système, ni de l’hébergement.
Étape 2 — Inspecter les dossiers sensibles
J’ai ensuite analysé :
wp-content/uploadswp-content/pluginswp-content/mu-plugins
C’est là que j’ai trouvé un fichier très suspect :
wp-content/uploads/system_cache.php
Ce type de fichier est une backdoor classique, utilisée pour réinjecter du code malveillant.
Mais même en le supprimant, il revenait.
Étape 3 — Découverte du vrai problème : des processus PHP malveillants en cours d’exécution
Le tournant de l’enquête est arrivé avec cette commande :
ps aux | grep php
Résultat :
/opt/cpanel/ea-php81/root/usr/bin/php /home/.../wp-content/x06f239/39076d
/opt/cpanel/ea-php81/root/usr/bin/php /home/.../wp-content/x06f239/139d0b6
/opt/cpanel/ea-php81/root/usr/bin/php /home/.../wp-content/x06f239/278eabcc
...
Plusieurs scripts PHP malveillants tournaient en tâche de fond, lancés directement depuis le dossier infecté.
Tant qu’ils étaient actifs, ils recréaient :
- les fichiers supprimés
- les dossiers infectés
- les backdoors dans
uploads - le
.htaccessetindex.php
C’était une infection persistante en mémoire, extrêmement rare sur un hébergement mutualisé.
Étape 4 — Neutraliser les processus malveillants
Pour reprendre la main, j’ai dû tuer tous les processus liés au dossier infecté :
pkill -f "wp-content/x06f239"
Une fois les processus stoppés, les fichiers ne se recréaient plus.
Étape 5 — Suppression définitive des fichiers infectés
Avec les scripts en mémoire neutralisés, j’ai pu supprimer :
rm -rf wp-content/x06f239
rm -rf 65705
rm -f wp-content/uploads/system_cache.php
rm -f index.php
rm -f .htaccess
Cette fois, ils ne revenaient plus.
Étape 6 — Identifier la source de la réinfection
Pour comprendre comment les scripts étaient lancés, j’ai inspecté :
Les crons utilisateur
crontab -l
Les fichiers du site
grep -R "x06f239" -n .
Les fichiers récemment modifiés
find . -type f -mtime -1
Ces vérifications permettent de repérer :
- un cron malveillant
- un plugin infecté
- un MU-plugin caché
- un include dans
wp-config.php
Dans mon cas, la source était un ensemble de fichiers dans x060f239 exécutés en tâche de fond.
Étape 7 — Réinstaller un WordPress propre
Une fois la backdoor éliminée, j’ai réinstallé le cœur WordPress :
wp core download --force
Cela remplace :
wp-adminwp-includes- les fichiers racine du core
Sans toucher :
wp-contentwp-config.php
Puis j’ai régénéré un .htaccess propre.
Conclusion : comment éviter que cela ne se reproduise
Voici les leçons à retenir :
✔️ 1. Surveiller les processus PHP
Un malware qui tourne en tâche de fond est invisible si on ne regarde pas les processus.
✔️ 2. Inspecter
C’est le dossier préféré des hackers pour déposer des backdoors.
✔️ 3. Vérifier les MU-plugins
Ils se chargent avant tout le reste et sont parfaits pour une infection persistante.
✔️ 4. Utiliser WP‑CLI pour restaurer le core
C’est la méthode la plus propre après un hack.
✔️ 5. Toujours chercher la source, pas seulement les symptômes
Supprimer les fichiers infectés ne sert à rien tant que la backdoor tourne en mémoire.
