# Je nettoie mon site et l’infection revient le lendemain

> Vous supprimez les fichiers signalés, tout redevient normal quelques heures, puis le problème réapparaît à l’identique : il reste un point de rechargement quelque part, et il se trouve rarement là où le scanner regarde.

- Source canonique : [https://allaux.fr/securite/infection-revient-apres-chaque-nettoyage](https://allaux.fr/securite/infection-revient-apres-chaque-nettoyage)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Listez d’abord le contenu de wp-content/mu-plugins/ : ce dossier se charge à chaque affichage de page sans apparaître dans la liste des extensions, et c’est le point de rechargement le plus fréquent. Passez ensuite en revue les tâches planifiées et les thèmes inactifs. Tant que le composant vulnérable d’origine n’est pas identifié puis mis à jour ou retiré, le nettoyage suivant est déjà programmé.

## Pourquoi un nettoyage partiel garantit la récidive

Quand une infection revient à l’identique après un nettoyage, il s’agit rarement d’une nouvelle attaque. C’est la même compromission qui se réinstalle, à partir d’un composant que le nettoyage n’a pas touché. Un site compromis contient en général deux catégories de fichiers : ceux qui produisent l’effet visible — redirection, page injectée, script inattendu sur le tunnel de commande — et ceux qui servent à les reposer. Les premiers sont bruyants, un scanner les trouve. Les seconds sont discrets, et souvent placés dans des emplacements que le tableau de bord n’affiche pas.

Tant que le mécanisme de rechargement est en place, supprimer les fichiers signalés revient à balayer devant une porte restée ouverte. Le délai typique, quelques heures ou une nuit, correspond simplement à la fréquence à laquelle ce mécanisme se déclenche. C’est d’ailleurs un indice utile : une réapparition régulière, à heure ou à intervalle fixe, désigne une tâche planifiée bien plus qu’une attaque manuelle répétée.

La conséquence pratique est simple : tant que je n’ai pas trouvé par où le code revient, je considère que le site est toujours compromis, même s’il paraît propre.

## Ce qui indique qu’il reste un point de rechargement

- Les mêmes fichiers réapparaissent, avec le même nom ou un nom très proche, quelques heures après leur suppression.
- Le scanner déclare le site propre, mais le comportement anormal revient : redirection, page inconnue, script ajouté dans les pages.
- L’infection revient alors que vous avez déjà changé tous les mots de passe.
- Un compte administrateur que vous aviez supprimé réapparaît.
- Le retour se produit à intervalle régulier plutôt qu’à un moment aléatoire.
- Restaurer une sauvegarde règle le problème quelques jours, puis il revient à l’identique.

## Pourquoi un scanner qui regarde la liste des extensions passe à côté

WordPress dispose d’un dossier d’extensions à chargement automatique, wp-content/mu-plugins/, dit « must-use ». Le code qui s’y trouve est chargé à chaque affichage de page, sans activation préalable, et il n’apparaît pas dans la liste des extensions du tableau de bord. C’est précisément ce qui en fait une cachette efficace. Sucuri a documenté en mars 2025 l’usage de ce dossier par des attaquants, avec trois fichiers observés : redirect.php, qui redirige les visiteurs vers une page extérieure malveillante déguisée en mise à jour de navigateur ; index.php, un webshell donnant un accès distant au serveur ; et custom-js-loader.php, qui remplace le contenu du site par des liens indésirables et manipule les images.

Un outil qui compare la liste affichée dans l’administration à une liste de référence ne verra rien de ce dossier, puisque son contenu n’y figure jamais. Le même angle mort existe côté thèmes. Une campagne analysée par Sucuri en mai 2025 injectait son code dans le fichier header.php de tous les thèmes installés, y compris ceux qui n’étaient pas actifs, pour afficher au visiteur une fausse page de vérification anti-robot. Nettoyer le thème actif laisse alors intactes autant de copies qu’il reste de thèmes sur le serveur : il suffit d’en activer un, ou qu’un processus le fasse, pour que tout revienne.

Les recommandations de détection tiennent en quelques points : surveiller les comportements inhabituels (redirections, modifications de fichiers), vérifier les permissions anormales, mettre en place un contrôle d’intégrité des fichiers, contrôler les comptes administrateurs, tout maintenir à jour et activer la double authentification.

## Les points de persistance, dans l’ordre où je les vérifie

1. **Les extensions à chargement automatique** — Je liste le contenu de wp-content/mu-plugins/ avant tout le reste. Sur beaucoup d’installations saines, ce dossier n’existe même pas. S’il existe et contient des fichiers que personne n’a demandés, c’est le point de rechargement à traiter en premier, parce qu’il s’exécute à chaque page sans jamais s’afficher dans l’administration.
2. **Les thèmes non actifs** — Je relis le fichier d’en-tête de chaque thème présent sur le serveur, pas seulement celui du thème actif. Un thème inutilisé reste un fichier lisible et modifiable, et il conserve l’injection intacte après le nettoyage du thème en place. Un thème que vous n’utilisez pas et que vous ne comptez pas utiliser doit être supprimé, pas désactivé.
3. **Les tâches planifiées** — Je liste les événements du planificateur. Dans la campagne d’hameçonnage analysée par Patchstack en avril 2025, l’extension malveillante programmait une tâche WP-Cron au nom aléatoire exécutée chaque minute, qui réinstallait la charge. Une tâche dont vous ne reconnaissez pas le nom, avec une fréquence anormalement élevée, doit être traitée comme une réinfection programmée.
4. **Le fichier de fonctions du thème actif** — Lors de la compromission de la chaîne de distribution ShapedPlugin publiée en juin 2026, un code chargeur était injecté dans le functions.php du thème actif et lisait une charge encodée en base64. C’est un emplacement parfaitement légitime, modifié par de nombreuses extensions : il se relit ligne par ligne, il ne se scanne pas.
5. **Les comptes administrateurs** — Je compare la liste des comptes à privilèges à ce que vous attendez réellement. Plusieurs campagnes créent des comptes administrateurs, parfois masqués de la liste des utilisateurs affichée dans le tableau de bord. Un seul compte oublié rouvre l’accès complet, quel que soit le soin apporté au nettoyage des fichiers.
6. **Les clés et jetons d’API** — Mots de passe applicatifs, clés d’API, jetons OAuth des services connectés, secrets de double authentification : s’ils ont pu être lus, les régénérer est la seule mesure qui coupe l’accès. Un attaquant qui détient encore un jeton valable n’a pas besoin de la porte dérobée que vous venez de supprimer.

## Vérifications de base (shell et WP-CLI)

```
ls -la wp-content/mu-plugins/
wp cron event list
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp theme list
find wp-content/themes -name "header.php"
find . -type f -name "*.php" -mtime -14
```

## La règle qui évite le troisième nettoyage

> Je ne remets pas un site en ligne tant que le point d’entrée n’est pas identifié, et pas seulement les fichiers déposés. Savoir ce qui a été supprimé ne dit pas par où l’attaquant est passé ; tant que la réponse manque, le même chemin reste disponible et le nettoyage suivant est déjà programmé. L’ordre que je tiens est toujours le même : composant vulnérable identifié puis mis à jour ou retiré, points de persistance vidés, comptes à privilèges vérifiés, secrets régénérés, et seulement ensuite remise en ligne.

## Pour aller plus loin

- **Nettoyer un site infecté** — La procédure complète, dans l’ordre, quand le site est déjà compromis. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Se protéger après un nettoyage** — Ce qui reste à faire une fois les fichiers retirés, pour que la porte ne se rouvre pas. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))
- **Un fichier inconnu sur le serveur** — Comment qualifier un fichier que vous n’avez pas déposé avant de le supprimer. ([/securite/fichier-inconnu-sur-le-serveur](/securite/fichier-inconnu-sur-le-serveur))
- **Vérifier si mon site est compromis** — Les contrôles à faire quand le doute existe mais que rien n’est encore confirmé. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))

## FAQ

### Pourquoi l’infection revient-elle toujours au bout de quelques heures ?

Parce qu’un mécanisme de rechargement subsiste et se déclenche à intervalle fixe. Une tâche planifiée au nom aléatoire exécutée chaque minute a été documentée dans une campagne analysée par Patchstack ; tant qu’elle est en place, la suppression des fichiers ne tient que jusqu’à sa prochaine exécution.

### Mon scanner dit que le site est propre, est-ce que je peux m’y fier ?

Pas seul. Un outil qui se base sur la liste des extensions affichée dans le tableau de bord ne voit pas le contenu de wp-content/mu-plugins/, qui est chargé sans activation et n’y figure jamais. Je vérifie ce dossier à la main, systématiquement.

### Faut-il nettoyer les thèmes que je n’utilise pas ?

Oui, et il vaut mieux les supprimer. Une campagne documentée par Sucuri injectait son code dans le fichier header.php de tous les thèmes installés, actifs ou non. Un thème inactif reste un fichier sur le serveur, donc une copie intacte de l’injection.

### Restaurer une sauvegarde suffit-il à régler le problème ?

Rarement. Si la sauvegarde est postérieure à la compromission, elle contient déjà le point de rechargement. Si elle est antérieure, elle remet aussi en place la version vulnérable par laquelle l’attaquant est entré. Une restauration ne remplace pas l’identification du point d’entrée.

### Dois-je changer les clés d’API même si j’ai retiré tous les fichiers ?

Oui, dès lors qu’un webshell ou un code chargeur a pu s’exécuter sur le serveur. Un jeton ou une clé encore valable donne un accès qui ne dépend plus d’aucun fichier présent sur le site.

### Quand puis-je considérer que c’est terminé ?

Quand le composant par lequel l’attaquant est entré est identifié et corrigé, que les points de persistance sont vides, que la liste des comptes à privilèges correspond à ce qui est attendu et que les secrets ont été régénérés. Avant cela, le site n’est pas nettoyé, il est seulement calme.