Un malware WordPress n’est pas la maladie, c’est le symptôme. Le supprimer sans fermer la porte par laquelle il est entré revient à le réinstaller soi-même quelques jours plus tard. Voici la méthode complète, dans l’ordre où elle se pratique.
Si vous n’êtes pas encore certain d’être infecté, commencez plutôt par reconnaître un site WordPress piraté.
Reconnaître une infection
Un malware se trahit rarement par un message d’erreur. Il se voit à des effets de bord : des redirections qui ne se déclenchent que depuis les moteurs de recherche ou depuis un mobile, des pages inconnues indexées à votre nom, du code ajouté en tête de fichiers PHP, des fichiers PHP dans le dossier des médias, un pic de consommation sans rapport avec le trafic, ou des courriels sortants que personne n’a envoyés.
Les scanners du marché repèrent bien les infections connues, et c’est utile. Mais ils travaillent sur signatures : un code écrit pour une cible précise leur échappe, et ils ne disent jamais par où l’attaquant est entré. Un scan vert n’est pas une preuve d’absence ; il dit seulement que rien de connu n’a été reconnu.
Pourquoi supprimer le fichier visible ne suffit pas
C’est l’erreur qui fait revenir l’infection, et elle est logique : on trouve un fichier étrange, on le supprime, le symptôme disparaît, on considère l’affaire close.
Sauf qu’un accès installé ne tient jamais à un seul fichier. Il s’accompagne généralement d’un compte administrateur discret, d’une tâche planifiée qui recrée le code à heure fixe, d’une ligne ajoutée dans un fichier légitime que personne ne relit, et parfois d’une entrée en base de données qui réinjecte le script à chaque affichage. Supprimer la partie visible laisse tout le reste en place.
Et surtout : la faille d’origine reste ouverte. Tant qu’elle l’est, le nettoyage le plus soigneux ne fait que gagner quelques jours.
Sauvegarder, puis analyser avant de toucher
Première action : une sauvegarde complète, fichiers et base de données, mise de côté. Elle est infectée, c’est normal — elle sert de preuve, et de point de retour si le nettoyage casse quelque chose.
Ensuite seulement, l’analyse. La méthode fiable n’est pas de chercher « du code suspect » à l’œil : le code malveillant est écrit pour ressembler au reste. C’est la comparaison avec les fichiers officiels. Le cœur de WordPress se compare à l’archive de sa version exacte, chaque extension et le thème à leur version d’origine : tout fichier modifié ou ajouté ressort immédiatement. Un thème sur mesure n’a pas de référence publique : il se relit, ou se compare à son dépôt.
La date du premier symptôme délimite la fenêtre à examiner dans les journaux du serveur et dans les dates de modification.
Le nettoyage
Le nettoyage découle de l’analyse, pas l’inverse. Les fichiers du cœur et des extensions modifiés sont remplacés par leur version officielle plutôt que corrigés à la main. Les fichiers ajoutés sont retirés. Dans un thème sur mesure, chaque ajout est relu avant suppression : on y trouve parfois du code légitime qui n’a jamais été documenté.
Viennent ensuite les endroits qu’un nettoyage pressé oublie : .htaccess et wp-config.php, où se logent redirections conditionnelles et inclusions discrètes ; la base de données, dont les options et les contenus peuvent porter des scripts injectés ; et les autres sites du même hébergement — sur un mutualisé, une infection voyage d’un dossier à l’autre.
Comptes, extensions, tâches planifiées
- Les comptes : supprimer ceux qui ne correspondent à personne, vérifier les rôles des autres — un compte d’auteur promu administrateur ne saute pas aux yeux.
- Les extensions et thèmes : désinstaller ce qui n’est pas utilisé, et tout ce qui vient d’une source autre que le répertoire officiel ou l’éditeur.
- Les tâches planifiées : une tâche inconnue peut reconstruire un accès chaque nuit, longtemps après le nettoyage.
- Les clés et mots de passe : hébergement, base de données, comptes WordPress, et les clés de salage de
wp-config.php, qui invalident d’un coup toutes les sessions encore ouvertes.
Mises à jour et durcissement
C’est l’étape qui décide si le nettoyage tient : mettre à jour le cœur, les extensions, le thème et la version de PHP, souvent oubliée alors qu’elle est l’étage sur lequel tout repose. Supprimer ce qui ne sert plus, activer les mises à jour automatiques de sécurité, et protéger l’accès à l’administration — double authentification et limitation des tentatives de connexion.
Les failles publiées qui touchent réellement les sites WordPress sont documentées dans Report Backdoor, avec les versions corrigées et la vérification à faire.
La surveillance après intervention
Un site déclaré propre doit le rester quelques jours : c’est le délai au bout duquel une porte oubliée se manifeste. On surveille l’apparition de fichiers hors des emplacements normaux, la recréation de comptes, le retour des redirections, et les journaux du serveur.
Ensuite seulement, si Google avait affiché un avertissement, on lui demande un nouvel examen depuis la Search Console. Demander trop tôt fait perdre des jours.
Au-delà, le risque ne disparaît pas : il se déplace vers la prochaine faille publiée. Un site nettoyé aujourd’hui redevient vulnérable le jour où une extension qu’il utilise est touchée — d’où l’intérêt d’une surveillance continue plutôt que d’un contrôle annuel.