Un site WordPress infecté, ce n’est pas seulement une question de “nettoyage”. C’est un problème de contrôle, de restauration de confiance et de prévention des retours. J’ai vu des sites reprendre la main en une journée, puis retomber deux semaines plus tard, parce qu’on avait retiré ce qui était visible sans traiter le point d’entrée. D’autres fois, le malware n’était même plus un fichier à supprimer, mais un accès persistant via un compte administrateur ajouté discrètement, une tâche planifiée, ou un script injecté dans un thème “qui a l’air” propre.
L’objectif n’est pas de trouver un responsable en une soirée. L’objectif est de retrouver un état maîtrisé, puis de durcir suffisamment pour que l’infection ne trouve plus de chemin.
Avant de toucher quoi que ce soit : stabiliser la situation
Quand on découvre une infection, la première erreur consiste à multiplier les suppressions et les changements “à la main” dans l’urgence. Supprimer des fichiers au hasard peut casser l’instance, et surtout, vous prive d’indices. Une bonne réponse commence par la stabilisation.
Regardez ce que vous observez, et mesurez l’impact. Le site redirige-t-il vers une page de spam ? Est-ce que des pages “Produit”, “About”, “Contact” sont modifiées ? Voyez-vous une hausse de 404, des requêtes vers des endpoints bizarres, ou des tentatives de connexion qui explosent dans les logs ? Si vous avez accès aux logs serveur, c’est souvent là que la chronologie devient claire, avant même de toucher au code.
Dans les faits, la stabilisation a deux volets. D’abord, empêcher l’infection de continuer à faire des dégâts pendant que vous enquêtez. Ensuite, conserver des preuves suffisamment longtemps pour savoir ce que vous avez vraiment retiré.
Sur le plan opérationnel, cela signifie souvent mettre le site en mode maintenance ou le désactiver temporairement (sans pour autant effacer les traces serveur). Même si les visiteurs n’ont plus accès, les logs continuent d’aider à comprendre le comportement.
Geler l’accès et protéger le périmètre
Un site infecté est rarement “seulement” infecté. Il peut aussi être en train d’ouvrir des portes. Tant que vous ne savez pas comment l’attaquant s’est introduit, considérer que le mot de passe du moment est fiable serait un pari risqué.
Prenez le contrôle, puis segmentez. Si vous avez plusieurs environnements (staging, production), la meilleure pratique consiste à traiter la production comme compromis tant que le diagnostic n’est pas terminé.
Concrètement :
- changez les mots de passe des comptes WordPress et des comptes liés (hébergement, FTP/SFTP, bases de données, accès administrateur au panneau de contrôle), déconnectez les sessions si votre hébergeur ou WordPress le permet, et évitez de travailler en production avec des comptes “personnels” dont vous ne connaissez pas l’historique.
À ce stade, il n’est pas utile de “trouver le plus gros fichier suspect” à la louche. Travaillez plutôt avec une logique d’accès, puis de modification.
Sauvegarder correctement, pas juste “faire une copie”
La tentation est de faire un export WordPress et de cloner le dossier. Oui, ça aide, mais ça ne suffit pas toujours. Pour nettoyer proprement, vous aurez besoin de pouvoir comparer, restaurer, et prouver ce que vous avez changé.
Une sauvegarde “utile” dans un contexte d’infection ressemble à un dossier de travail. Je conseille d’en faire au moins deux variantes : 1) une archive complète des fichiers du site (répertoires WordPress, thèmes, plugins, uploads), 2) une sauvegarde de la base de données.
Si vous utilisez un plugin de sauvegarde, faites-en un dernier avant toute modification majeure, puis travaillez avec vos archives. Évitez les sauvegardes trop compressées ou automatisées qui finissent par supprimer les anciennes versions. L’infection peut laisser des traces dans la base, mais aussi dans des fichiers rarissimes, comme un script placé dans un répertoire rarement utilisé.
Si le site https://gardewp.fr/securite-wordpress/ est extrêmement instable, une approche réaliste est de copier en priorité les éléments sensibles : wp-content, wp-config.php, et la base. Mais gardez l’idéal, une archive complète, pour analyser ensuite.
Diagnostiquer sans se raconter d’histoires
Une infection WordPress peut se manifester de dizaines de façons. Certains compromis consistent en quelques lignes de code injectées, d’autres en une chaîne de redirections, d’autres encore en l’ajout d’un compte administrateur avec un accès persistant.
Avant de supprimer, tentez de répondre à une question simple : qu’est-ce qui change, et où ?
Les symptômes typiques que j’observe le plus souvent
Il y a des signaux assez reconnaissables, surtout si vous suivez la Search Console ou si votre hébergeur alerte sur des comportements anormaux.
Voici ceux qui reviennent le plus :
Le site affiche un contenu différent de celui attendu, parfois seulement pour certains pays ou certains navigateurs, Des redirections vers des pages de type “casino”, “pharma” ou sites de téléchargement, Des pages “cachées” ajoutées automatiquement dans le thème ou le contenu, Une hausse soudaine des tentatives de connexion, des profils utilisateurs qui apparaissent sans explication, Des fichiers nouveaux ou modifiés récemment dans wp-content (thèmes, plugins, ou uploads).Selon le cas, votre plan de nettoyage ne sera pas identique. Si vous voyez une redirection, ce n’est pas forcément un “virus” au sens classique. Cela peut être un script injecté dans un fichier modèle, ou un chargement conditionnel dans un thème.
Attention aux faux positifs
WordPress, ce n’est pas un système figé. Les plugins de sécurité, les optimisateurs d’image, les cacheurs et certains thèmes “builder” peuvent modifier des fichiers, créer des caches, ou injecter des balises. Si vous supprimez sans comprendre, vous risquez de casser le site ou de supprimer un composant légitime.
Votre diagnostic doit donc comparer “avant” et “après” quand c’est possible. Les timestamps des fichiers (ou l’historique Git si vous en utilisez) sont utiles. Les logs sont encore plus fiables, parce qu’un attaquant peut faire des modifications, mais les requêtes laissent une trace.
Le nettoyage : méthode, pas improvisation
Le nettoyage d’un site déjà infecté n’est pas une opération unique. C’est une suite de décisions. En pratique, on avance par étapes, du plus probable au plus difficile, et on valide à chaque moment.
Pour garder une logique claire, voici une chronologie opérationnelle, adaptée aux cas où le site est en production et où vous devez retrouver une maîtrise rapide.
Couper l’exposition : mettez le site en maintenance, désactivez temporairement les plugins non essentiels, et isolez le trafic si votre hébergeur le permet. Conservez les logs. Réinitialiser l’accès : changez mots de passe, retirez les comptes inconnus, forcez une déconnexion des sessions, et vérifiez les rôles (administrateur, éditeur, auteur) et les adresses mail. Nettoyer le code : comparez wp-core, wp-content et fichiers sensibles. Réinstallez WordPress si nécessaire, et remplacez thèmes et plugins par des versions officielles, puis éliminez les éléments inconnus dans uploads et wp-content. Nettoyer la base : recherchez des traces dans wp options, wppostmeta, wp users, wpposts. L’objectif est de supprimer les injections de code, shortcodes malveillants et entrées suspectes, sans casser votre contenu légitime. Valider puis durcir : scannez, testez toutes les pages clés, vérifiez que les redirections ont cessé, puis appliquez des mesures de protection site WordPress (durcissement, limitations d’accès, monitoring).
Cette séquence évite un piège fréquent : “je nettoie, puis je redonne accès”. Sans réinitialisation d’accès, vous risquez d’enlever le malware visible et de laisser intacte la porte par laquelle il revient.
Retirer la persistance : comptes, tâches, champs “invisibles”
Une infection revient souvent parce qu’elle se maintient. WordPress offre plusieurs lieux de persistance. Les attaquants exploitent ce que l’interface leur donne, ou ce qu’un plugin leur permet.
Le premier réflexe consiste à vérifier les utilisateurs. Certains ajouts sont évidents, nom et adresse inconnus. D’autres sont plus subtils : un compte créé avec un nom banal, un avatar inoffensif, puis utilisé pour modifier des fichiers ou publier des contenus. Supprimez ce qui n’est pas de votre contrôle, mais surtout, changez les identifiants et vérifiez la sécurité de l’hébergement, car un compte WordPress ne doit pas être votre seule barrière.
Ensuite, examinez les fichiers qui exécutent du code au démarrage. Même si le cœur de WordPress est souvent intact, un thème modifié peut injecter un script dans wp_head ou dans le footer, avec une logique conditionnelle. Les chargements conditionnels sont une vraie difficulté, car le code malveillant ne se déclenche pas toujours, ce qui donne l’impression de “nettoyage réussi” alors que le comportement reste sporadique.
Enfin, surveillez les tâches planifiées (si votre configuration utilise cron WordPress). Certains compromis créent une tâche qui recharge un contenu distant, injecte un lien, ou crée des brouillons “pendants”.
Remplacer plutôt que “réparer” dans wp-content
Quand un site est infecté et que vous n’êtes pas certain de l’intégrité de chaque fichier, la stratégie la plus fiable consiste souvent à remplacer.
Le raisonnement est simple : WordPress core, thèmes et plugins ne devraient pas être “trafiqués” en profondeur. Si vous avez un thème personnalisé, il peut être difficile de distinguer ce qui est utile de ce qui est malveillant. Dans ce cas, vous pouvez sauvegarder le thème, le comparer avec la version attendue, et remettre à plat les fichiers suspects.
Pour les plugins et thèmes que vous n’avez pas customisés, la meilleure approche reste de les réinstaller depuis les sources officielles, puis de vérifier que les versions correspondent. Un attaquant peut ajouter un fichier dans un plugin légitime ou dans un thème “fourre-tout”. Remplacer réduit la surface de risque.
Pour les thèmes custom, je recommande une approche prudente : redéployer les fichiers d’origine si vous les avez, puis réappliquer uniquement les modifications que vous pouvez justifier. Quand on n’a aucune traçabilité, on finit par nettoyer à l’aveugle, et ce n’est pas tenable à long terme.
Scans et nettoyage, sans tomber dans la dépendance
Il existe des outils de scan. Certains sont efficaces, d’autres donnent surtout de l’anxiété. Un scan peut vous dire qu’un fichier est “suspect”, mais pas toujours pourquoi, ni comment il a été injecté. Et surtout, un scan peut rater des charges conditionnelles.
Dans un contexte professionnel, je traite les scans comme un guide, pas comme l’arbitre final. Si un outil identifie une signature dans un fichier, vérifiez le contexte. Un fichier injecté au bon endroit est dangereux, même si la signature est minimaliste. À l’inverse, une signature “malveillante” dans un fichier de cache peut être un faux positif, selon l’outil.
Ce qui compte, c’est la validation fonctionnelle. Si les redirections ont cessé, si les pages clés renvoient le contenu attendu, si les tentatives étranges dans les logs ont diminué, vous avancez dans la bonne direction.
La base de données : souvent le vrai champ de bataille
Sur les sites infectés, la base de données contient parfois le code ou les paramètres qui pilotent la modification front. WordPress stocke beaucoup de choses dans wp_options et dans des métadonnées de posts. Certains compromis ajoutent des options pour rendre un script actif, injectent des balises dans des options d’apparence, ou créent des articles “support” invisibles pour l’utilisateur.
Sans inventer de méthode “magique”, le principe est de comparer ce qui est anormal. Les chaînes longues et incohérentes, les valeurs qui ressemblent à du JavaScript encodé, ou des modifications d’options “nommées” de manière obscure peuvent indiquer une injection.
Mais attention à la méthode. Si vous supprimez trop vite une option sans comprendre, vous pouvez casser un plugin légitime ou perdre une partie des réglages. Là encore, les sauvegardes et la possibilité de restaurer en cas d’erreur font la différence.
Une astuce pratique : si vous avez des horodatages, repérez quand la base a changé. Les tables de logs, s’il y en a, et les changements d’options peuvent révéler le moment de l’infection, ce qui aide ensuite à recouper les fichiers modifiés.
Validation après nettoyage : prouver que le problème est parti
Après un nettoyage, l’erreur classique consiste à remettre le site en ligne trop vite, sans test réel. Or, une infection peut n’être déclenchée que dans certaines conditions. Vous devez donc valider de manière ciblée.
Testez au minimum :
- la page d’accueil, la navigation principale et une page “contact”, une page de type article, et une page “catégorie”, le comportement du header et du footer, car les injections se cachent souvent dans wp_head ou via des scripts chargés en fin de page.
Côté sécurité, vérifiez aussi le retour des redirections, même en navigation privée. Une infection peut laisser un comportement qui dépend du cache navigateur. J’ai déjà vu des équipes annoncer “nettoyé” alors qu’en navigation normale tout semblait correct, puis en navigation privée la redirection revenait.
Enfin, surveillez les logs après remise en ligne. Si les requêtes malveillantes continuent au même rythme, ou si de nouveaux fichiers apparaissent, cela signifie souvent que la persistance n’a pas été éliminée.
Durcir après incident : la protection site WordPress doit être une routine
Nettoyer, c’est remettre le site à l’endroit. Durcir, c’est empêcher le retour. Beaucoup de “protection site WordPress” se joue sur des détails qui semblent modestes, mais qui changent radicalement l’économie de l’attaque.
Le durcissement ne se limite pas à installer un plugin de sécurité. C’est un ensemble : politique de mots de passe, gestion des rôles, mise à jour, limitation du bruteforce, et hygiène des fichiers.
Quelques leviers utiles, à adapter selon votre contexte :
- Mettez à jour régulièrement WordPress, thèmes et plugins, surtout les composants exposés côté front. Réduisez le nombre de plugins actifs. Chaque plugin est une surface, même si vous lui faites confiance. Renforcez l’accès administrateur : mots de passe uniques, limitation des tentatives de connexion, et idéalement une double authentification. Désactivez l’édition de fichiers depuis WordPress si elle n’est pas nécessaire. Vérifiez les permissions de fichiers et de répertoires, surtout dans wp-content/uploads et sur les fichiers qui contiennent des scripts. Surveillez l’apparition de nouveaux fichiers dans wp-content. Les périodes de déploiement sont celles où vous pouvez justifier des changements, le reste du temps, c’est suspect.
Je préfère aussi une logique “alertes tôt, action rapide”. Par exemple, si votre hébergeur ou votre stack renvoie des alertes sur les pics de 404, les erreurs 500 ou les pics de requêtes vers des endpoints inhabituels, agissez avant que le site ne soit en état critique.
Un point que je surveille toujours : les mises à jour et les régressions
Durcir peut provoquer des effets secondaires. Une règle trop stricte de firewall peut bloquer des requêtes légitimes, un durcissement de cookies peut casser un plugin de formulaire, et une limitation trop agressive sur le login peut gêner vos clients si vous avez un environnement partagé.
C’est pour ça que je conseille de valider, même en sécurité. Les bonnes protections sont celles que vous pouvez maintenir, pas celles qui “font joli” pendant trois jours.
Trade-offs et cas limites : quand ce n’est pas seulement WordPress
Parfois, le malware n’est pas dans WordPress. Il est dans l’infrastructure : un script injecté au niveau du serveur, un reverse proxy compromis, une mauvaise configuration de cache, ou un plugin qui charge du contenu distant.
Si vous avez accès à la configuration web (Nginx, Apache) et si vos fichiers WordPress semblent intacts mais que le comportement reste anormal, il faut élargir l’enquête. Le symptôme ressemble à une infection WordPress, mais la cause peut être ailleurs. Dans ces cas, s’acharner uniquement sur wp-content vous fera perdre du temps.
Il y a aussi un cas fréquent, plus “organisationnel”. Un site est maintenu par plusieurs personnes, les accès sont partagés, et on ne sait plus qui a modifié quoi. Le retour d’infection peut venir d’une restauration depuis une sauvegarde contaminée, ou d’un déploiement qui réintroduit un fichier infecté. La protection site WordPress devient alors un sujet de gouvernance, pas seulement de technique.
Mettre en place un plan d’exploitation “post-incident”
Une fois l’incident traité, vous gagnez beaucoup à transformer l’expérience en procédure. Je ne parle pas d’un document lourd, mais d’un plan simple.
L’idée : réduire le temps de diagnostic et augmenter la qualité des décisions la prochaine fois. Vous pouvez par exemple décider dès maintenant :
- quel type de sauvegarde vous conservez, combien de temps, et comment vous vérifiez la restauration, comment vous gérez les comptes (revue mensuelle des utilisateurs, désactivation des comptes inutiles), et comment vous auditez les changements de fichiers.
Quand une équipe a un rituel de revue, elle détecte plus vite les anomalies. Et elle évite aussi la tentation de “corriger au symptôme” sans traiter la porte d’entrée.
Liste d’actions pratiques pour un retour rapide à la stabilité
Voici une courte checklist, utile si vous devez agir vite, mais sans vous perdre dans la foule de détails.
Désactiver ou mettre en maintenance, sans supprimer les logs Changer tous les identifiants, vérifier utilisateurs et rôles Remplacer thèmes et plugins non custom depuis des sources officielles Contrôler les injections dans la base de données (options et métadonnées) Valider le comportement en navigation normale et privée, puis surveiller les logsEn suivant ce fil, vous avez une chance réelle de sortir du cycle “nettoyage, puis retour”.
Ce que “sécuriser un site déjà infecté” change dans votre façon de travailler
La sécurité ne devient pas une affaire de plugin, elle devient une affaire de méthode. Un site propre n’est pas seulement un site débarrassé d’un code malveillant, c’est un site dont vous pouvez expliquer l’intégrité.
Quand un incident arrive, le réflexe sain est de regarder le chemin. Comment l’attaquant a eu accès ? Via un mot de passe faible ? Via un plugin dépassé ? Via un thème non maintenu ? Via une restauration d’une sauvegarde contaminée ? Une fois ces questions répondues, la protection site WordPress n’est plus une liste de mesures, c’est une stratégie ciblée.
Si vous devez retenir une seule idée, c’est celle-ci : nettoyer sans éliminer la persistance, c’est comme fermer une fenêtre tout en laissant une clé sur la porte. Le problème ne part pas, il attend simplement le prochain créneau.
Si vous me donnez votre contexte, taille du site, plugins majeurs, type d’hébergement et symptômes exacts (redirection, contenus modifiés, comportement sporadique), je peux vous proposer une démarche de nettoyage et de durcissement plus spécifique, avec les contrôles les plus rentables en premier.