Technique et prévention · 10 min · publié le 24 octobre 2025

Pourquoi le site se réinfecte en 48 heures

La porte permet de réécrire ce que vous venez de retirer. Compte admin fantôme, cron, voisin de serveur, mot de passe d'hébergement inchangé : quatre causes, toujours les mêmes. Le lendemain n'est pas un nouveau pirate. C'est ce que vous n'avez pas fermé la veille.

Réponse directe

La porte permet de réécrire ce que vous venez de retirer. Compte admin fantôme, cron, voisin de serveur, mot de passe d'hébergement inchangé. Quatre causes, toujours les mêmes.

site réinfecté malware revient piratage revient lendemain

Ce que « 48 heures » veut dire

Ce n'est pas une loi physique. C'est le délai habituel d'un cron, d'une visite de bot, ou d'un humain qui vérifie que sa porte répond. Un retour en vingt minutes dit plutôt : session encore ouverte ou script encore en mémoire / cache. Un retour à J+10 dit parfois une porte rare, ou une nouvelle entrée (extension toujours vulnérable). On date, on ne mythifie pas.

Le guide résume. Ici, on sépare les quatre causes pour cesser de « nettoyer la home » en boucle.

Réinfecté n'est pas « Google qui n'a pas compris ». L'index est lent ; un fichier qui *réapparaît* sur le disque, c'est une écriture.

Cause 1 : la porte fichiers

Vous avez retiré le spam SEO, pas le one-liner. Il réécrit. Méthode : trouver la porte, comparer à l'officiel. Tant qu'un PHP inattendu exécute, le cycle continue.

Les uploads exécutables et le 777 accélèrent la réécriture. Filets : no PHP uploads, permissions. Ils ne remplacent pas la chasse, ils réduisent la facilité.

Un `.htaccess` handler fait exécuter un « jpg ». Vous croyez avoir nettoyé les PHP. Voir htaccess.

Cause 2 : le compte qui reste

Admin CMS fantôme, utilisateur FTP ajouté, application password, clé REST, session non invalidée. Pas de nouveau fichier : un humain ou un script *légitime* du point de vue du CMS réécrit le contenu. Chassez les utilisateurs, révoquez, tuez les sessions.

Le mot de passe *panel* encore ancien : l'attaquant repose le fichier que vous venez d'enlever, via le gestionnaire de fichiers. C'est la cause la plus bête et la plus fréquente des dossiers « on a tout changé » (ils avaient changé wp-admin seulement).

2FA après, pas à la place. Double authentification n'efface pas un compte `adm1n` déjà là.

  • Panel / FTP en premier.
  • Admins CMS + clés.
  • Sessions mortes.

Cause 3 : le cron et la tâche

Panel cron, cron système, wp-cron qui charge un PHP, tâche planifiée Windows sur un VPS, webhook qui « ping » une URL de repose. Le rythme 24–48 h colle souvent à ça. Inventaire *écrit* des crons, une ligne = une justification métier.

Une tâche « backup » qui télécharge une archive sale et l'extrait : vous avez programmé la réinfection. Isolez les backups.

Désactiver wp-cron sans regarder le cron serveur laisse parfois *leur* tâche et casse *vos* publications. Lisez avant de couper.

Cause 4 : le voisin et le panel

Autre site du même utilisateur, isolation faible, `open_basedir` cosmétique. Vous nettoyez A, B réécrit A. Carte du compte entier, pas « mon WordPress ». Parfois, l'hébergeur doit isoler — sous-traitant host. Vous, vous cessez d'entasser des sites morts.

Un access.login panel depuis un pays inattendu après « tout changé » : le secret panel n'a pas changé, ou la 2FA SMS va sur une ligne perdue.

Migration sale : le nouveau serveur se réinfecte en 24 h. Ce n'est pas l'hébergeur B qui est « moins bon ». C'est la copie.

Les fausses pistes

Cache CDN / plugin qui ressert l'ancienne home : ça *ressemble* à une réinfection. Purgez, voyez si le disque change. Object cache idem.

Google qui montre encore le spam : l'index, pas le disque. `site:` lent ≠ fichier revenu.

Un salarié qui « remet l'ancienne version du thème » depuis sa clé USB de 2022 : réinfection humaine. Communication interne.

La checklist du lendemain

Disque : nouveaux PHP, htaccess changé. CMS : nouveaux users. Panel : nouveaux FTP, crons. Mail : files, règles. Visiteur : mobile / privé. Si un item bouge, vous avez la cause, pas besoin d'un sixième scanner.

Notez « inchangé » aussi. Ça évite de re-vérifier en rond sans méthode.

Les logs de cette fenêtre sont précieux. Ne réinstallez pas « pour voir » le matin.

Quand arrêter de tourner en rond

Deux cycles symptôme / retrait sans carte complète : déléguez. Le coût d'un troisième amateur dépasse l'intervention. Créer un compte en joignant « ce qui revient, à quelle heure, ce qui a déjà été changé (panel ? non) ». Cette phrase oriente en cinq minutes.

Si l'entrée applicative (extension) n'est pas patchée, la porte reviendra *même* après une chasse parfaite. MAJ ou retrait du composant. Autre cause, même délai.

Documentez pour l'assureur : réinfection = preuve que le premier geste était incomplet, pas que « c'est impossible à nettoyer ».

  • Quatre causes, une à une.
  • Panel avant le thème.
  • Carte, puis 48 h, puis aide.

Questions fréquentes

On a changé d'adresse IP. Ça continue. Pourquoi ?

+
L'IP n'est pas la porte. La copie des fichiers et des secrets l'est. Changer d'IP pendant que le compte est sale déplace le problème.

Un plugin de firewall empêche-t-il la réinfection ?

+
Il peut gêner un brute force. Il ne voit pas un mu-plugin déjà là, ni un FTP ouvert. On le pose après, filet.

C'est revenu en 10 minutes. Les 48 h sont fausses ?

+
Le titre décrit le cas fréquent. Dix minutes = souvent session / process / cache / FTP encore là. Même checklist, plus serrée.

L'hébergeur a « malwaré » le fichier encore. Ils le font exprès ?

+
Non. Leur scanner revoit un fichier *reposé*. Demandez l'heure, croisez avec vos crons et le FTP.

Faut-il couper le site 48 h pour « casser le cycle » ?

+
Rarement utile. Couper n'invalide pas un cron interne ni un FTP. Ça coûte du SEO. Isolez l'URL sale, pas tout le domaine, sauf phishing / mineur actif.
À lire ensuite
Backdoor c'est quoi Trouver la porte Page backdoor Guide Journalisation 30 jours Déclarer mon site