Site WordPress réinfecté après nettoyage : pourquoi le malware revient-il ?

Votre site WordPress a été nettoyé, les fichiers signalés ont été supprimés et le scanner ne détectait plus rien. Quelques heures ou quelques jours plus tard, une redirection réapparaît, un fichier suspect est recréé, de nouveaux spams sont envoyés ou l’hébergeur bloque de nouveau le site.

Cette situation ne signifie pas automatiquement que le premier nettoyage n’a servi à rien. Elle montre surtout qu’un élément permettant la persistance ou la réintroduction du malware n’a pas été identifié : porte dérobée restée active, vulnérabilité toujours exploitable, accès compromis, tâche planifiée, sauvegarde contaminée, autre site infecté sur le même hébergement ou injection encore présente dans la base de données.

Il faut aussi distinguer une véritable réinfection d’un signal qui met du temps à disparaître. Une ancienne page peut rester visible dans Google, une alerte navigateur peut persister après le nettoyage ou une réputation d’envoi dégradée peut continuer à produire des erreurs alors que le code malveillant n’est plus actif.

La bonne réponse n’est donc pas de relancer exactement le même nettoyage. Il faut comparer ce qui revient, préserver les éléments utiles et contrôler l’ensemble de la chaîne d’accès. Ce guide explique pourquoi un malware WordPress peut revenir après nettoyage, comment qualifier la récidive et quand demander un nettoyage malware WordPress approfondi.

Un site réinfecté signifie-t-il que le même malware est revenu ?

Pas nécessairement. Une récidive peut correspondre à quatre situations différentes :

Situation observée	Interprétation possible	Contrôle prioritaire
Le même fichier réapparaît au même emplacement	Un mécanisme de persistance ou une tâche le recrée	Origine des écritures, tâches planifiées, fichiers chargeurs et journaux
De nouveaux fichiers suspects apparaissent après le nettoyage	Le point d’entrée ou un accès compromis reste actif	Extensions, thèmes, comptes, SFTP, hébergement et appareils utilisés
Le problème revient juste après une restauration	La sauvegarde peut être contaminée ou la cause n’a pas été corrigée	Date réelle de compromission, contenu de la sauvegarde et vulnérabilité initiale
Google, le navigateur ou l’hébergeur affiche encore une alerte sans nouveau fichier	Signal résiduel, cache, index ou réputation encore non actualisés	État technique actuel, codes HTTP, rapports externes et date du dernier contrôle
Le symptôme change de forme	Plusieurs composants étaient compromis ou une nouvelle intrusion a eu lieu	Chronologie, empreintes, accès et périmètre complet de l’hébergement

Le terme « réinfection » est donc pratique, mais il ne doit pas remplacer le diagnostic. Avant de conclure qu’une backdoor a survécu, il faut établir si le site a conservé un mécanisme de persistance, s’il a été de nouveau compromis ou si l’alerte observée est simplement en retard sur la correction.

Qu’est-ce qu’une backdoor WordPress ?

Une backdoor, ou porte dérobée, est un moyen caché de retrouver un accès ou de réexécuter une action sans repasser par le fonctionnement normal du site. Dans un WordPress compromis, elle peut prendre la forme d’un fichier ajouté, d’une modification dans un composant existant, d’un compte administrateur non autorisé, d’une tâche planifiée, d’une instruction stockée dans la base de données ou d’un accès technique encore valide.

La backdoor n’est pas forcément le contenu malveillant visible. Elle peut rester discrète et servir uniquement à télécharger, recréer ou activer une autre charge. Supprimer la redirection, la page spam ou le fichier détecté ne retire donc pas toujours le mécanisme qui permet leur retour.

Pourquoi un malware WordPress revient-il après nettoyage ?

1. Le nettoyage a supprimé le symptôme, mais pas le mécanisme de persistance

Un scanner ou une alerte d’hébergeur peut désigner un fichier précis. Le supprimer peut stopper temporairement le comportement observé, sans retirer le fichier qui l’a créé, la tâche qui le régénère ou le compte qui permet de le réinstaller.

La documentation officielle WordPress consacrée aux sites piratés rappelle notamment qu’une réinstallation partielle peut écraser des fichiers existants sans éliminer les nouveaux fichiers introduits par l’attaquant. Le répertoire wp-content, les fichiers de configuration et les règles serveur nécessitent une analyse spécifique.

2. La vulnérabilité initiale est toujours exploitable

Le nettoyage enlève le code malveillant, mais il ne corrige pas automatiquement la faille qui a permis son installation. Une extension abandonnée, un thème non maintenu, une version obsolète, des permissions inadaptées ou une configuration exposée peuvent permettre une nouvelle intrusion.

Le guide officiel Hardening WordPress insiste sur les mises à jour, les permissions, les sauvegardes, la journalisation et la surveillance. Si un composant ne peut plus être mis à jour, son remplacement ou sa suppression doit être envisagé plutôt qu’un simple maintien en production.

3. Un accès compromis reste valide

L’attaquant peut revenir sans exploiter une nouvelle faille s’il dispose encore d’un accès fonctionnel. Le périmètre ne se limite pas au mot de passe WordPress :

• compte de l’hébergeur ou du panneau d’administration ;
• FTP, SFTP ou SSH ;
• base de données ;
• compte administrateur WordPress ;
• boîte e-mail utilisée pour les réinitialisations ;
• compte d’agence, de développeur ou de maintenance ;
• service tiers connecté au site.

WordPress recommande de revoir l’ensemble des points d’accès et de tous les utilisateurs, pas seulement le compte principal. Les changements doivent être réalisés depuis un appareil fiable afin d’éviter de réexposer immédiatement les nouveaux identifiants.

4. Un compte, un rôle ou une session non autorisés subsistent

Un administrateur inconnu peut continuer à modifier le site après le nettoyage. Il faut également contrôler les rôles, les comptes de service, les invitations, les utilisateurs inactifs et les sessions encore ouvertes.

Le remplacement des clés de sécurité WordPress permet d’invalider les sessions existantes, mais il doit s’inscrire dans une révision plus large des comptes et des accès. Supprimer un utilisateur visible ne suffit pas si l’adresse e-mail, le compte d’hébergement ou un autre canal de réinitialisation reste compromis.

5. Une tâche planifiée recrée les fichiers ou relance le code

WordPress utilise WP-Cron pour exécuter des tâches différées ou récurrentes. L’hébergement peut également comporter des tâches serveur. Pendant un diagnostic de récidive, tout événement inconnu, récemment ajouté ou sans composant légitime identifiable doit être vérifié.

Une réapparition à intervalle régulier constitue un indice utile : le fichier revient après chaque visite, toutes les heures, après une tâche de maintenance ou après une action précise. Cet horaire ne prouve pas à lui seul l’origine, mais il permet de rapprocher les écritures de fichiers, les événements planifiés et les journaux.

6. L’injection est restée dans la base de données ou une zone moins visible

Un nettoyage centré sur les fichiers peut laisser des scripts, redirections, options, widgets, contenus ou comptes dans la base de données. D’autres zones sont souvent moins examinées : extensions obligatoires, fichiers « drop-in », caches persistants, configuration du serveur, fichiers .htaccess, répertoires d’uploads ou règles chargées avant WordPress.

À l’inverse, une chaîne suspecte dans la base n’est pas automatiquement malveillante. Certains constructeurs, outils de cache et extensions stockent du code ou des données sérialisées. Toute suppression doit être précédée d’une sauvegarde et d’une qualification du rôle de l’élément.

7. Une sauvegarde, un site de test ou une autre installation réintroduit l’infection

Une sauvegarde prise après le début de la compromission peut restaurer le malware en même temps que le site. Une copie de préproduction, un ancien domaine, un sous-répertoire oublié ou un second WordPress situé dans le même compte d’hébergement peut également rester infecté.

Les documentations WordPress distinguent la sauvegarde des fichiers et la sauvegarde de la base de données. Pour évaluer une restauration, il faut connaître la date de chaque élément, son origine, le périmètre sauvegardé et la date probable du premier accès non autorisé.

8. Le signal externe persiste alors que le site a été corrigé

Un résultat Google, une alerte de sécurité, un cache CDN, un blocage d’e-mails ou une réputation d’adresse IP ne sont pas toujours actualisés immédiatement après le nettoyage. Leur persistance peut donner l’impression que le malware est revenu.

Il faut alors contrôler l’état réel : contenu servi actuellement, code HTTP, redirections, date du dernier crawl, journaux d’envoi, nouvelle détection de fichier et chronologie de l’alerte. Si aucune nouvelle trace technique n’apparaît, le problème peut relever d’un processus de réexamen ou de mise à jour externe plutôt que d’une réinfection.

Que faire pendant la première heure après la récidive ?

Période	Objectif	Actions prudentes
0 à 10 minutes	Documenter le retour	Noter l’heure, le symptôme, les URL, les chemins, les messages et les personnes ayant constaté le problème
10 à 20 minutes	Préserver l’état actuel	Conserver une copie, les journaux, les rapports de scan et le compte rendu du premier nettoyage
20 à 30 minutes	Comparer les incidents	Identifier ce qui est identique, différent, périodique ou déclenché par une action
30 à 45 minutes	Limiter l’exposition	Protéger les visiteurs, paiements, formulaires ou envois concernés sans effacer les preuves
45 à 60 minutes	Préparer le diagnostic	Rassembler les accès, sauvegardes, dates, composants modifiés et actions déjà menées

Si le site est en train de rediriger, d’envoyer des messages frauduleux ou de présenter une page de phishing, le confinement prime sur l’observation prolongée. La mesure doit rester proportionnée et, si possible, être coordonnée avec l’hébergeur ou l’intervenant.

Que doit vérifier un diagnostic de réinfection WordPress ?

Le diagnostic doit dépasser le fichier qui vient de réapparaître. Il cherche à expliquer comment l’élément a été créé, par quel accès et à quel moment.

Zone	Objectif	Exemples de contrôles
Cœur WordPress	Repérer les fichiers modifiés ou ajoutés	Version, intégrité et comparaison avec les fichiers officiels
Extensions et thèmes	Identifier un composant altéré, vulnérable ou abandonné	Origine, version, fichiers supplémentaires, mises à jour et composants inutilisés
wp-content et zones particulières	Contrôler les emplacements moins visibles	Uploads, mu-plugins, drop-ins, caches, sauvegardes locales et répertoires temporaires
Base de données	Rechercher les injections et accès persistants	Utilisateurs, rôles, options, contenus, widgets, redirections et tâches stockées
Comptes et sessions	Vérifier qui peut encore intervenir	Administrateurs, comptes prestataires, sessions, e-mails et méthodes de récupération
Tâches planifiées	Identifier une exécution récurrente	WP-Cron, tâches serveur et scripts automatisés
Hébergement et journaux	Reconstituer les écritures et connexions	Accès, erreurs, modifications, connexions SFTP/SSH et requêtes inhabituelles
Autres sites et environnements	Éviter une contamination croisée	Sous-domaines, staging, anciennes versions, multisite et autres installations du compte
Sauvegardes	Déterminer si une source propre existe	Dates, contenu, lieu de stockage, historique des restaurations et tests
Services externes	Contrôler les canaux de réintroduction ou les signaux résiduels	SMTP, API, CDN, Search Console, DNS, e-mails et outils d’automatisation

Lorsque l’accès en ligne de commande est disponible, les commandes officielles WP-CLI pour vérifier le cœur et les extensions distribuées sur WordPress.org peuvent aider à repérer des différences. Elles ne couvrent toutefois pas tous les thèmes, extensions premium, fichiers personnalisés, contenus de base de données ou fichiers ajoutés hors des paquets officiels.

Un scanner qui indique « site propre » suffit-il ?

Non. Un résultat propre est un signal positif, mais pas une preuve absolue. Les scanners n’examinent pas tous le même périmètre et ne détectent pas tous les comportements personnalisés. Certains comparent les fichiers officiels, d’autres recherchent des signatures, analysent le site à distance ou contrôlent des comportements visibles.

La documentation WordPress recommande de combiner plusieurs approches plutôt que de considérer un outil unique comme définitif. Dans le cadre d’une récidive, le scan doit être rapproché de la chronologie, des journaux, des comptes, des tâches planifiées et des différences observées entre les deux incidents.

Un scanner peut également signaler un fichier légitime modifié pour les besoins du site. Toute correction automatique doit donc être précédée d’une sauvegarde et d’une validation du rôle du fichier.

Faut-il restaurer une sauvegarde lorsque le malware revient ?

Une restauration peut être pertinente si la sauvegarde est antérieure à la compromission et si son contenu est connu. Elle ne doit pas être utilisée comme réponse automatique.

Situation	Décision prudente
La date du premier accès malveillant est connue et une sauvegarde complète plus ancienne existe	Tester la sauvegarde dans un environnement isolé, puis corriger le point d’entrée avant la remise en ligne
La sauvegarde a été prise après les premiers symptômes	La considérer comme potentiellement contaminée et l’analyser avant toute restauration
Seule la base de données ou seuls les fichiers sont sauvegardés	Vérifier que l’autre composant dispose d’une source compatible et propre
Le site est réinfecté immédiatement après chaque restauration	Arrêter les restaurations répétées et rechercher la cause, l’accès ou la source contaminée
Aucune sauvegarde fiable n’est disponible	Procéder à un nettoyage contrôlé, remplacer les composants depuis leurs sources officielles et documenter les éléments conservés

Même avec une sauvegarde saine, les mots de passe, sessions, extensions vulnérables, permissions et autres installations du compte doivent être contrôlés. Sinon, le site restauré peut être compromis de nouveau par le même chemin.

Les erreurs qui entretiennent la récidive

Supprimer à chaque fois le fichier qui revient

Cette action fait disparaître le symptôme sans identifier ce qui écrit le fichier. Elle peut aussi effacer une information utile pour relier la récidive à un événement ou à un accès.

Relancer le même nettoyage automatique

Si le premier passage n’a pas identifié la cause, répéter la même méthode produit souvent le même résultat. La récidive doit déclencher un élargissement du périmètre et une comparaison des incidents.

Changer uniquement le mot de passe WordPress

L’accès peut provenir de l’hébergement, du SFTP, d’une boîte e-mail, d’une API ou d’un compte prestataire. Tous les accès doivent être inventoriés et renouvelés selon le niveau de compromission.

Restaurer plusieurs sauvegardes en production pour « tester »

Chaque restauration modifie la chronologie, peut écraser les journaux et risque de réintroduire du code malveillant. Les tests doivent être réalisés dans un environnement isolé lorsque cela est possible.

Ignorer les anciens sites, dossiers et sous-domaines

Une installation oubliée peut rester vulnérable sur le même compte d’hébergement. Le diagnostic doit porter sur tout ce qui partage les mêmes accès ou permissions, pas seulement sur le domaine principal.

Déclarer le site sain parce que la page d’accueil fonctionne

Une infection peut ne toucher que certains visiteurs, certaines URL, les e-mails, Google ou une tâche différée. Vérifiez les fonctions critiques et les indicateurs initiaux, pas seulement l’apparence de la page d’accueil.

Comment savoir si le site est réellement stabilisé ?

Il n’existe pas de délai universel garantissant qu’un site est propre. La durée d’observation dépend de la fréquence de la récidive, du niveau de criticité, des journaux disponibles et des mécanismes identifiés.

Les éléments suivants doivent converger :

• les fichiers, pages, redirections ou envois à l’origine de l’alerte ne réapparaissent plus ;
• les composants officiels vérifiés restent stables entre deux contrôles ;
• les comptes, rôles, sessions et accès techniques sont maîtrisés ;
• les tâches planifiées ont une origine légitime identifiée ;
• la vulnérabilité ou le vecteur probable a été corrigé ;
• les autres installations et sauvegardes du compte ont été contrôlées ;
• les journaux ne montrent plus d’écriture, connexion ou comportement non autorisé ;
• les formulaires, commandes, paiements, e-mails et fonctions métier fonctionnent normalement ;
• une nouvelle sauvegarde complète et clairement identifiée a été créée après validation ;
• une surveillance est en place pour détecter rapidement toute nouvelle modification.

Le guide Après nettoyage d’un site WordPress piraté détaille la phase de stabilisation, les sauvegardes, les mises à jour et la surveillance après l’intervention.

Quelles informations préparer pour faire analyser la récidive ?

Pour accélérer le diagnostic, rassemblez :

• l’URL du site et le nom de l’hébergeur ;
• la date du premier incident, du nettoyage et de la récidive ;
• le rapport ou la liste des actions menées lors du premier nettoyage ;
• les chemins de fichiers, URL, captures et messages qui réapparaissent ;
• la fréquence ou les circonstances du retour ;
• les versions de WordPress, des extensions et du thème ;
• les comptes, accès et mots de passe déjà renouvelés ;
• les autres domaines, sous-domaines, sites de test et anciennes installations présents dans l’hébergement ;
• les dates et le contenu connu des sauvegardes ;
• les impacts sur les visiteurs, les commandes, les e-mails, Google ou l’hébergeur.

Ne transmettez aucun mot de passe dans le formulaire initial. Les accès éventuellement nécessaires doivent être communiqués séparément, de façon temporaire et selon le périmètre validé.

Questions fréquentes

Le retour du malware prouve-t-il qu’une backdoor est encore présente ?

Non. C’est une hypothèse importante, mais le site peut aussi avoir été compromis de nouveau par une vulnérabilité non corrigée, un accès toujours valide, une sauvegarde contaminée ou une autre installation infectée.

Pourquoi le même fichier revient-il après sa suppression ?

Un autre fichier, une tâche planifiée, une instruction en base de données, un cache ou un utilisateur peut le recréer. Notez l’heure exacte et évitez de le supprimer plusieurs fois avant d’avoir recherché l’origine de l’écriture.

Un plugin de sécurité peut-il stopper définitivement la réinfection ?

Il peut détecter, bloquer ou signaler certains éléments, mais il ne garantit pas à lui seul l’analyse de tous les accès, tâches serveur, sauvegardes, autres installations et services externes. La récidive exige généralement un diagnostic plus large.

Réinstaller WordPress suffit-il ?

Non. Remplacer le cœur peut corriger des fichiers officiels altérés, mais ne traite pas automatiquement wp-content, les fichiers ajoutés, la base de données, les comptes, les tâches planifiées, les accès d’hébergement ou la vulnérabilité initiale.

Comment savoir si une sauvegarde est propre ?

Comparez sa date avec le premier indicateur de compromission, vérifiez qu’elle contient les fichiers et la base de données nécessaires, puis testez-la dans un environnement isolé. Une sauvegarde antérieure aux symptômes peut tout de même être postérieure à l’accès initial.

Faut-il supprimer entièrement le site et repartir de zéro ?

Cela dépend du périmètre, des composants personnalisés, des données et des sauvegardes disponibles. Une reconstruction peut être pertinente dans certains cas, mais elle ne dispense pas de renouveler les accès et de corriger le point d’entrée.

L’alerte Google ou navigateur peut-elle rester après le nettoyage ?

Oui. Les services externes doivent parfois réexplorer ou réexaminer le site. Vérifiez d’abord que le contenu malveillant n’est plus servi, puis suivez la procédure de réexamen adaptée. Une alerte persistante sans nouvelle trace technique n’est pas forcément une réinfection.

Combien de temps faut-il surveiller le site après la correction ?

Il n’existe pas de durée identique pour tous les sites. La surveillance doit au minimum couvrir les cycles au cours desquels le problème revenait auparavant et être adaptée à la criticité du site. Les journaux, alertes de fichiers, comptes et fonctions métier doivent rester contrôlés dans la durée.