Quand un site WordPress est compromis, la première tentation est de “réinstaller et espérer”. J’ai déjà vu des retours où l’administrateur avait remis un thème propre, changé le mot de passe, puis constaté quelques jours plus tard une nouvelle vague d’injections. Le problème n’était pas seulement le thème ou le plugin, c’était la persistance, l’accès maintenu, et parfois une configuration globale qui avait été modifiée à bas bruit.
Le nettoyage après infection, c’est un mélange de chirurgie et d’hygiène. Chirurgie pour retirer tout ce qui a été ajouté, hygiène pour empêcher le retour. Et entre les deux, il faut accepter une règle simple: tant que vous n’êtes pas certain de ce qui a été modifié, chaque “petit correctif” peut masquer la cause.
Ce guide décrit une méthode réaliste, orientée terrain, pour sécuriser WordPress après un incident. Il ne s’appuie pas sur des promesses miracles, mais sur des vérifications et des décisions raisonnables.
Ce que signifie “infection” sur WordPress
Sur WordPress, les infections ne ressemblent pas toujours à un film. Parfois, ce sont des pages qui affichent du contenu bizarre à certaines heures, parfois des redirections, parfois un spam SEO intégré. Le plus trompeur, c’est que le site peut “sembler normal” pendant un moment, alors que l’attaquant conserve un accès via une porte dérobée.
Les scénarios courants que j’ai rencontrés ou observés chez des clients ressemblent souvent à ceci :
- Des fichiers PHP modifiés dans le dossier du thème ou des uploads, avec un code qui ne fait “rien” tant qu’une condition n’est pas remplie. Un plugin “gratuit” ou “légèrement suspect” ajouté dans le back-office, parfois avec un nom proche d’un plugin connu. Des comptes utilisateurs ajoutés, parfois avec un rôle élevé, parfois avec des adresses emails jetées au hasard. Un accès FTP ou SSH qui a été exploité, ou un cookie de session volé qui reste valide pendant un certain temps. Une modification de la base de données, avec des champs “options” ou des meta qui déclenchent des redirections. Un site injecté via le fichier .htaccess, ou via des règles côté serveur.
Le point clé, c’est que l’infection peut être à plusieurs niveaux à la fois. Si vous ne traitez que les symptômes visibles, vous laissez la “mécanique” derrière.
La première décision: isoler ou réparer en direct
Avant de toucher aux fichiers, je recommande de figer la situation. Isoler le site évite deux choses: d’une part, l’attaquant peut continuer à déposer de nouveaux éléments, d’autre part, vous limitez le risque que des visiteurs reçoivent du contenu malveillant pendant que vous intervenez.
Concrètement, vous avez plusieurs options selon votre contexte.
Si vous pouvez afficher une page de maintenance sans exposer l’application, c’est l’idéal. Si vous n’avez pas cette option, il vaut mieux couper l’accès au front-end ou limiter via le pare-feu. En revanche, couper totalement peut compliquer l’enquête interne. Mon approche consiste à préserver un accès administrateur pour inspecter, tout en empêchant l’extérieur de toucher au contenu.
Cette phase est aussi l’occasion de préparer une fenêtre d’intervention “propre”: sauvegardes, captures, relevés. Une infection est rarement une scène de crime “propre”. Si vous nettoyez trop vite, vous perdez le fil.
Mettre en pause: sauvegardes, relevés, et preuves utiles
Avant de remplacer des fichiers, faites des sauvegardes exploitables. Pas un simple zip de “tout le dossier”, mais quelque chose qui vous permet de revenir en arrière et de comparer.
Voici ce que je prépare systématiquement quand je passe en mode nettoyage:
- une copie complète des fichiers du site (au minimum les répertoires WordPress, themes, plugins, uploads, et tous les fichiers racine comme index.php, .htaccess, wp-config.php) une sauvegarde de la base de données (export complet) une copie des logs disponibles (access logs, error logs, logs du CMS si vous en avez) une liste des dates et comportements (quand ça a commencé, à quel moment, fréquence des redirections, pages touchées)
Ces éléments ne sont pas “du luxe”. Ils servent quand vous trouvez une modification étrange. Sans comparaison, vous avez vite fait de supprimer le mauvais fichier ou d’effacer la seule trace du point d’entrée.
Vérifier l’étendue avant de réécrire
Le nettoyage dépend de l’étendue. Le même plan ne s’applique pas si l’injection ne concerne que un thème, ou si des fichiers dans uploads sont compromis, ou si la base de données porte la charge.
Commencez par vérifier ce qui est “visible” côté usage, puis ce qui est “réel” côté système.
Côté usage, posez-vous des questions simples: y a-t-il des redirections vers une autre URL ? Certaines pages sont-elles touchées seulement ? Le problème apparaît-il seulement avec certains navigateurs ou certains pays ? Si vous avez un outil de monitoring, cherchez les pics autour de la date d’incident.
Ensuite, côté technique, examinez les points qui trahissent une manipulation: dates de modification des fichiers inhabituelles, plugins ajoutés récemment, comptes créés récemment, fichiers PHP dans des dossiers non attendus.
Cette vérification est aussi utile pour éviter le piège classique: “j’ai trouvé un fichier infecté, donc tout est réglé”. Souvent, il reste une seconde porte.
Contrôler les comptes et les sessions
Sur WordPress, beaucoup d’infections deviennent “persistantes” via un compte compromis. Le premier réflexe est de regarder les utilisateurs.
Si vous voyez un utilisateur ajouté récemment, surtout avec un rôle admin ou éditeur, c’est un signal fort. Mais ne vous contentez pas de supprimer. Un attaquant peut revenir, récréer un compte, ou réactiver un accès via un outil externe.
Il faut aussi invalider les sessions. WordPress stocke des jetons, et certains environnements peuvent garder des sessions longtemps. Vous pouvez forcer la déconnexion de tous les utilisateurs depuis des outils d’administration, ou en réinitialisant la configuration de session si vous avez accès à ce niveau.
Mon conseil: pendant le nettoyage, forcez un changement de mot de passe pour tout compte ayant des privilèges. Ne vous limitez pas à “l’admin principal”. Si un technicien a accès, s’il y a plusieurs admins, il faut traiter tout le monde.
Et oui, changez aussi les mots de passe liés: hébergement, FTP, base de données, compte administrateur du panneau d’hébergement. Une infection WordPress n’exclut pas un incident côté serveur.
Nettoyer le code sans casser l’écosystème
Le nettoyage “propre” consiste à repartir de sources saines, ou au minimum à retirer ce qui a été modifié sans raison.
Le piège des restaurations partielles, c’est que vous finissez par garder un morceau toxique. Par exemple, un attaquant ajoute une ligne dans un fichier du thème, puis s’appuie sur une autre modification plus discrète ailleurs. Si vous ne remplacez que le thème, mais que le code est dans un fichier secondaire, l’injection revient.
Dans la pratique, j’utilise deux approches selon la situation:
- Si vous avez des copies propres fiables de votre WordPress, thèmes et plugins, remplacez les répertoires concernés par des versions saines. Si vous n’avez pas de certitude, basculez sur une base de re-install complète et comparez, puis réintroduisez progressivement vos éléments.
WordPress est assez modularisé pour permettre une reconstruction progressive, à condition de garder vos fichiers de configuration (et de vérifier qu’ils n’ont pas été altérés).
Où cherchent les attaquants sur WordPress
Il y a des emplacements “classiques” où l’on retrouve du code malveillant. Je ne promets pas l’exhaustivité, mais voici les zones qui reviennent le plus.
1) Dans les thèmes et plugins
L’attaquant peut ajouter du code dans functions.php, un fichier de template, ou dans un plugin. Parfois, il ne s’active pas immédiatement, mais se déclenche sur certains critères (URL, user-agent, heure).2) Dans les fichiers uploads
Le dossier uploads peut contenir des images et des fichiers PHP déguisés, ou des scripts déposés via exploitation de formulaire. Je l’ai déjà vu: un fichier “.jpg.php” ou un contenu PHP injecté dans une extension anormale. 
3) Dans les fichiers racine
Des modifications de .htaccess sont fréquentes, surtout pour rediriger, injecter, ou établir des règles qui évitent d’afficher l’origine du problème.4) Dans wp-config.php
Rarement “massif” parce que les attaquants veulent rester discrets, mais on voit parfois des modifications ajoutant des requêtes ou des inclusions.5) Dans la base de données
Des valeurs options ou des contenus de pages peuvent être modifiés. Souvent, ce n’est pas juste du texte: il y a des structures qui déclenchent une redirection ou un hardening WordPress chargement externe.Si vous commencez à inspecter, commencez par les zones qui peuvent vous donner la réponse la plus rapide, puis élargissez.
Remplacer ce qui peut l’être, comparer ce qui doit l’être
Sur un site infecté, je préfère un raisonnement simple: supprimer tout ce qui pourrait venir de l’extérieur, puis réintroduire uniquement ce qui est nécessaire, et seulement après vérification.
Cela signifie souvent:
- désactiver et supprimer tous les plugins, puis réactiver un à un (si vous avez besoin de certains plugins, réinstallez-les plutôt que de conserver leurs fichiers) traiter chaque thème comme suspect sauf si vous pouvez démontrer sa propreté (ou utiliser un thème de base en remplacement temporaire) remplacer les fichiers WordPress core par une version officielle saine
Cette méthode évite une situation frustrante: trouver un fichier infecté dans un coin, supprimer la ligne, puis apprendre que le même code était dans un autre fichier, dans un autre plugin, ou dans une autre version.
Le coût est réel, mais il est souvent inférieur au coût d’une réinfection.
Sécuriser WordPress pendant le nettoyage: réduire l’attaque future
Le nettoyage n’est pas un événement unique, c’est une trajectoire. Une fois que vous avez retiré le code malveillant, vous devez réduire les surfaces d’entrée. C’est là que la sécurisation WordPress devient concrète.
La plupart des incidents que j’ai vus ont une cause combinée: un mot de passe faible ou réutilisé, un plugin obsolète, un manque de contrôle des accès, et parfois des erreurs d’exploitation côté serveur.
Vous n’avez pas besoin de tout verrouiller immédiatement, mais vous devez agir sur les points les plus rentables.
- Mettez à jour WordPress core, thèmes et plugins depuis des versions fiables. Attention aux plugins “non maintenus”. Réglez les permissions de fichiers, surtout sur les dossiers d’écriture. Désactivez ou supprimez les plugins dont vous n’avez pas besoin. Activez une double authentification pour les comptes admin (et encouragez-la pour les comptes éditeur). Limitez l’accès à wp-admin et wp-login si c’est possible dans votre contexte d’hébergement (via règles de serveur ou pare-feu applicatif).
Les compromis existent. Par exemple, une limitation d’accès peut gêner vos équipes si elles changent souvent de IP. Une double authentification peut freiner un client ou une petite équipe. Mais ces frictions sont souvent moins coûteuses que la récupération après réinfection.
Une méthode pratique de restauration progressive
Il est tentant de remettre le site “comme avant” dès que possible. Pourtant, le retour progressif réduit le risque de réinjecter un élément compromis.
Pendant cette étape, vous testez aussi l’état réel du site, pas seulement la page d’accueil.
Voici une approche que j’ai utilisée plusieurs fois, avec des résultats fiables:
- remplacez d’abord WordPress core, puis thèmes et plugins par des versions saines (en évitant de réutiliser des fichiers suspects) réinitialisez les identifiants de tous les comptes à privilèges, et invalidez les sessions rebranchez un thème propre en premier (si possible un thème stable) pour vérifier que le front et l’admin fonctionnent réactivez les plugins un par un, en testant les pages les plus exposées (contact, pages de landing, recherche, formulaires) mettez en place un contrôle post-restauration, avec surveillance des logs et vérification régulière des fichiers modifiés
Cette séquence n’est pas “magique”, mais elle rend l’origine d’une réinfection beaucoup plus lisible si elle survient.
Inspection ciblée: ce qu’il faut repérer dans les fichiers
Au moment de parcourir les fichiers, je cherche moins des signatures universelles, et plus des comportements suspects.
Ce qui m’intéresse en priorité:
- du code qui fait des inclusions dynamiques (include, require) avec des chemins non attendus des appels vers des domaines externes qui n’ont rien à voir avec votre activité du code qui base ses actions sur l’URL, sur des cookies, ou sur le user-agent des chaînes de caractères bizarres, encodées ou concaténées, souvent combinées à une logique d’exécution après conditions
Ne vous contentez pas de supprimer une ligne. Si un fichier contient une logique suspecte, le plus sûr est de le remplacer par une version officielle, ou par votre version propre issue de votre sauvegarde.
Edge case fréquent: un développeur a ajouté du code “raisonnable”, et l’attaque a emprunté le même emplacement pour se camoufler. Dans ce cas, supprimer en bloc peut casser une fonctionnalité légitime. D’où l’intérêt de comparer avec vos versions pré-incident ou vos sources versionnées.
Nettoyage base de données: quand il faut creuser
Quand le problème persiste malgré un remplacement des fichiers, la base de données devient suspecte. Il peut y avoir des modifications d’options, de contenus, ou des tables altérées.
Souvent, on découvre des redirections dans des champs “options”, ou des contenus de pages transformés en landing malveillantes. Parfois, ce sont des champs dans des tables de configuration qui ont été ajoutés.
Deux approches existent, avec des compromis:
- restaurer une sauvegarde de base de données antérieure à l’incident (si vous avez une date fiable et une sauvegarde propre) analyser la base et corriger les entrées suspectes (utile si vous ne pouvez pas restaurer complètement)
Si vous restaurez, vous devrez recaler l’état du site sur le bon moment. Sinon vous réintroduisez une partie de l’infection. Si vous analysez à la main, vous devez garder une trace exacte des modifications, sinon vous risquez de “nettoyer” quelque chose qui n’était pas compromis.
Quand je fais une restauration, je privilégie une sauvegarde datée avec certitude. Quand je corrige, je fais des comparaisons et je garde une sauvegarde de la base avant toute modification.
Tester avant de remettre en ligne
Un site peut sembler “propre” dans un navigateur, mais rester infecté dans un autre scénario.
Pendant la période de remise en ligne, je teste systématiquement:
- la page d’accueil et les pages qui ont des formulaires ou des redirections wp-admin (connexion, chargement, plugins) les pages anciennes, celles qui avaient pu être injectées les liens qui doivent pointer vers votre domaine (vérifier l’absence de redirections externes) les fichiers téléchargés via formulaires et médias
Si vous avez un système de cache (côté serveur ou plugin), attention. Le cache peut afficher l’ancienne page sans refléter le nettoyage, ce qui vous donne une fausse impression de victoire. Purgez ou neutralisez temporairement le cache pour tester “le réel”.
Surveillance post-nettoyage: éviter la “fausse fin”
Beaucoup de gens s’arrêtent après la restauration. En pratique, une infection se repère souvent par le retour du comportement, parfois quelques jours plus tard.
La surveillance doit être légère mais régulière. Elle peut être manuelle, ou via des outils de monitoring. Je recommande au minimum de surveiller:
- les logs d’accès pour les requêtes qui ciblent des fichiers ou des endpoints connus les erreurs PHP inhabituelles les changements de fichiers sensibles (si vous avez un outil de contrôle d’intégrité) la création de nouveaux utilisateurs
Vous gagnerez du temps en fixant un rituel. Par exemple, chaque jour pendant une semaine, puis chaque semaine pendant un mois, vérifier les éléments les plus indicateurs.
C’est moins “spectaculaire” que le nettoyage, mais c’est ce qui évite le retour à la case départ.
Deux erreurs qui coûtent cher
Sur le terrain, je vois deux erreurs se répéter.
La première: ne pas changer les identifiants liés au serveur. Si quelqu’un a eu accès à FTP ou au panneau d’hébergement, WordPress ne sera qu’un chapitre. L’accès restera valable.
La seconde: réinstaller “à l’identique” sans re-vérifier. Une restauration qui reprend les mêmes fichiers corrompus, ou qui réactive les mêmes plugins sans vérification, annule la démarche. Vous avez alors un incident, un nettoyage, puis un incident à nouveau, mais plus rapidement.
Il y a aussi un troisième piège plus discret: restaurer uniquement WordPress core en ignorant uploads et base. Les injections persistent justement là où on ne restaure pas.
Quand demander de l’aide (et comment choisir)
Si vous êtes seul, vous pouvez résoudre beaucoup d’incidents, surtout si l’infection est modérée. Mais si vous suspectez une exploitation profonde du serveur, ou si vous n’arrivez pas à identifier l’origine, demander de l’aide devient rationnel.
Pour cadrer un prestataire, je vous conseille de demander au minimum:
- quelles sources saines ils utilisent pour remplacer les fichiers (core, thèmes, plugins) comment ils valident qu’il n’y a plus de persistance (comptes, sessions, accès serveur) s’ils travaillent sur une base de sauvegardes datées comment ils testent la remise en ligne (front, admin, caches, redirections)
Le bon prestataire ne vous vend pas une “magie”. Il vous montre une méthode, et il garde des traces de ce qui a été modifié.
Récap rapide des décisions à prendre
Le nettoyage après infection n’est pas une simple action “supprimer un fichier”. C’est une série de décisions, et certaines sont plus importantes que d’autres.
La règle d’or, c’est la suivante: si vous n’êtes pas sûr, remplacez par du sain, purgez les caches, réinitialisez les accès, puis testez avant de réouvrir. Ensuite, sécurisez WordPress pour rendre la prochaine tentative beaucoup plus difficile.
Une infection laisse rarement un seul indice. En revanche, elle laisse souvent une logique de persistance. La bonne approche consiste à la couper au niveau des fichiers, des comptes, et du serveur, puis à surveiller.
Si vous voulez, dites-moi votre configuration (hébergement, présence d’un cache, type de symptôme, date approximative, plugins récents). Je peux vous proposer une démarche de diagnostic plus ciblée, adaptée à votre cas, sans vous faire perdre du temps sur des pistes qui ne collent pas.