Quand un malware touche WordPress, il ne se contente pas toujours de “défigurer” un site. Le scénario le plus vicieux, celui que je rencontre souvent chez les sites déjà un peu bricolés, consiste à modifier le comportement de WordPress sans forcément casser l’affichage immédiat. Et, dans le fil du temps, on finit par voir des champs apparaître dans des formulaires, des pages d’options, ou dans l’interface d’édition. Parfois ce sont des champs de type “hidden” injectés via le front. Parfois ce sont des champs côté base de données, par exemple dans les options, les métadonnées des contenus, ou les champs de profil utilisateur.
Le “nettoyage virus WordPress” dans ce cas ne se limite pas à supprimer des fichiers. Il faut aussi corriger les champs ajoutés par le malware, sinon le problème revient, ou il reste un morceau actif qui continue à injecter du code ou à détourner les soumissions.
Je vais te montrer une approche pragmatique, centrée sur ce qui arrive réellement dans WordPress, sur les endroits où un malware laisse des traces, et sur la façon de remettre d’aplomb les champs ajoutés. L’idée est simple: comprendre où le malware a “rangé” ses paramètres, puis supprimer ces paramètres sans casser le reste de ton installation.
Le symptôme: des champs qui n’ont pas d’explication “métier”
Le point de départ, c’est le symptôme. Le malware peut ajouter des champs de plusieurs manières, et ton mode d’observation compte.
- Dans l’administration: tu vois apparaître des champs sur des écrans qui n’en ont jamais eu, par exemple dans un plugin de formulaires, dans la configuration d’un thème, ou dans des pages de réglages. Ces champs peuvent porter des noms très génériques (“enable”, “tracking”, “script”, “redirect”), ou au contraire une chaîne longue, parfois proche d’un identifiant de campagne. Dans le front: tu vois des champs invisibles dans le HTML des formulaires, ou des champs qui ressemblent à du spam, par exemple des champs récupérés ensuite par un script. Même si tu ne les “remplis” jamais, ils peuvent être là pour déclencher une redirection ou injecter des paramètres. Dans la base: tu observes des valeurs ajoutées dans wp_options, wp_usermeta, wp_postmeta, ou des entrées dans une table “à côté”. Le site semble normal, mais certains éléments se déclenchent selon des conditions, comme l’URL, la session ou l’agent utilisateur.
Je me souviens d’un site e-commerce où un faux bloc “newsletter” apparaissait seulement sur certaines pages, sans changer le rendu global. En inspectant le code et les requêtes, on a retrouvé un champ injecté dans les métadonnées d’un formulaire, puis réutilisé côté PHP via une option stockée en base. Tant qu’on supprimait le fichier malveillant, mais qu’on laissait les options, le comportement revenait dès qu’un autre visiteur passait par une page d’édition, ce qui relançait un morceau de logique.
D’abord, sécuriser: sinon tu risques de “corriger”… au mauvais endroit
Avant de toucher aux champs, il faut arrêter la propagation et éviter de rendre le diagnostic impossible.
Tu veux répondre à trois questions:
1) Est-ce que le site exécute encore du code malveillant maintenant, ou est-ce que c’est un artefact déjà sauvegardé dans la base qui s’exécute encore? 2) Est-ce que le malware a un mécanisme de persistance, comme une tâche Cron, un script dans un fichier PHP accessible, ou une entrée dans un thème ou un plugin? 3) Est-ce qu’on doit restaurer entièrement à partir d’une sauvegarde, ou peut-on faire un nettoyage ciblé?
Dans la pratique, je fais rarement “au feeling”. Je procède de façon structurée, avec un minimum d’outillage, même simple.
Checklist incident (réduire les dégâts, garder une trace)
- Prendre une sauvegarde complète, fichiers + base de données, même si elle est “ancienne” (elle sert à comparer et à revenir en arrière). Mettre WordPress en maintenance ou bloquer temporairement le trafic externe vers les pages sensibles. Repérer et neutraliser la persistance (fichiers modifiés, plugins injectés, Cron, fichiers dans des dossiers inattendus). Identifier l’endroit exact où les champs sont injectés (front, back-office, ou base) avant de supprimer des valeurs. Après correction, vérifier le comportement sur plusieurs comptes (administrateur, éditeur, visiteur) et plusieurs pages d’entrée.
Cette étape évite un piège fréquent: supprimer des champs “que tu vois”, alors que le malware a laissé une logique qui les reconstitue à partir d’un autre endroit, souvent une option ou un hook.
Comprendre où un malware “range” ses champs dans WordPress
WordPress propose de nombreux points d’entrée. Un malware qui ajoute des champs n’a pas besoin de tout casser. Il peut stocker des paramètres n’importe où.
Voici les zones les plus typiques, celles que je regarde en premier quand https://gardewp.fr/ je dois corriger des champs ajoutés.
1) wp_options: le coffre aux réglages invisibles
Beaucoup de malwares passent par wp_options pour stocker des scripts, des paramètres, des URLs de redirection, ou des flags qui conditionnent l’injection. Les valeurs peuvent être codées, parfois compressées ou en “chunks”, mais tu retrouves souvent des entrées dont le préfixe est inhabituel.
Signaux d’alerte utiles:
- Options avec des noms très “techniques” ou au contraire trop génériques. Valeurs contenant des fragments de code PHP, des balises HTML, ou des chaînes qui ressemblent à des chemins de fichiers. Changements de tailles très brutaux: une option “normale” devient énorme, ou une nouvelle option apparaît après une date précise.
Ce n’est pas “automatiquement malveillant”. Un plugin légitime peut créer une option à forte taille, et certains thèmes peuvent stocker des configurations. La différence, c’est le contenu et le contexte: une valeur qui contient du PHP et qui n’est pas attendue par un plugin connu, ou une option qui n’est liée à aucun réglage visible.
2) wp_usermeta: champs liés aux comptes compromis
Si le malware a compromis un compte administrateur, il peut ajouter des métadonnées utilisateur. Par exemple, il peut enregistrer un paramètre pour forcer une redirection après connexion, ou il peut stocker des options pour déclencher une injection sur certaines pages.
Ici, les “champs ajoutés” ne se voient pas forcément comme des champs UI. Ils apparaissent comme des paires clé-valeur dans wp_usermeta, associées à un utilisateur.
Je vérifie aussi les champs du profil. Parfois tu vois un champ supplémentaire côté profil, ou une extension de la gestion utilisateur via un plugin. Parfois, c’est silencieux.
3) wp_postmeta: métadonnées de formulaires, pages et contenus
Si tes “champs” apparaissent sur une page ou sur un type de contenu précis, inspecter wp_postmeta est souvent révélateur. Un malware peut ajouter une métadonnée qui ressemble à une config de plugin, ou au contraire une clé au nom opaque. Ensuite, le code du plugin ou du thème lit cette clé et construit le rendu.
Edge case important: un constructeur de pages ou un plugin de formulaires peut créer des métadonnées très nombreuses et parfois impressionnantes. Le malware ne se “distingue” pas uniquement par le fait qu’il y a beaucoup de lignes, mais par la présence de valeurs suspectes ou par l’apparition récente de clés qui n’étaient pas là avant.
4) Fichiers PHP dans thème ou plugin: injection au moment de l’affichage
Les champs ajoutés peuvent aussi être injectés à l’exécution, via:
- un filtre ou hook, une fonction qui modifie le contenu HTML, un script qui ajoute des balises dans le rendu des formulaires, un chargement de fichier depuis un endroit non standard.
Même si le malware stocke ses paramètres en base, l’endroit qui ajoute les champs au HTML est souvent dans un fichier modifié.
Dans un nettoyage efficace, tu ne fais pas juste “supprimer l’option”. Tu neutralises aussi la logique d’injection. Sinon tu corriges la base une fois, mais le script malveillant recrée la valeur à la prochaine exécution.
Identifier “quels champs” ont été ajoutés, sans tirer au hasard
Le mot “champs” peut vouloir dire deux choses: des champs visibles dans l’interface, et des champs de données stockés dans la base. Les deux peuvent exister en même temps.
La méthode que je privilégie est basée sur la corrélation.
1) Repérer quand les champs apparaissent (sur quelles pages, pour quels rôles, à quel moment). 2) Comparer avant/après si tu as une sauvegarde. 3) Faire le lien avec une injection: si les champs apparaissent uniquement à l’affichage d’une page spécifique, je cherche d’abord les hooks liés à ce template ou à ce plugin. Si les champs apparaissent côté administration, je regarde plutôt les hooks d’admin ou les réglages de plugin. 4) Ensuite, seulement ensuite, je passe à la base pour enlever les entrées associées.
Exemple concret: champ invisible dans un formulaire
Supposons que tu vois un formulaire normal, mais avec un champ hidden qui n’était pas là. Tu inspectes le HTML et tu retrouves une clé de configuration qui ressemble à un identifiant marketing ou à une instruction.
Si tu inspectes le code source de la page générée, tu trouveras souvent une valeur injectée depuis PHP. À partir de là, deux scénarios:
- La valeur vient d’une option WordPress lue par le plugin, puis réinjectée en HTML. La valeur vient directement d’un fichier PHP injecté qui ajoute le champ.
Dans le premier scénario, corriger la base suffit souvent, à condition de supprimer aussi la logique qui lit l’option (ou de supprimer l’option si la logique est inoffensive). Dans le second scénario, supprimer seulement les champs de la base peut être temporaire, car la logique malveillante reste active et recréera les valeurs.
C’est pour ça que, même quand le symptôme est “des champs ajoutés”, je ne néglige pas les fichiers.
Le nettoyage pas à pas: corriger les champs ajoutés sans casser le site
Je vais te donner une démarche très concrète. Elle n’est pas une recette universelle, parce que le malware s’exprime différemment selon l’objectif, mais la logique reste la même: neutraliser la persistance, puis nettoyer les données associées.
1) Vérifier l’intégrité des fichiers WordPress et du contenu modifié
Avant de toucher à la base, je fais un tri. Beaucoup de malwares modifient un fichier dans:
- le thème actif, un plugin installé, parfois un fichier “mu-plugin”, ou un fichier noyé dans des sous-dossiers non attendus.
Même sans outil avancé, tu peux repérer des différences via les dates de modification. Un plugin modifié la veille d’un incident, sans raison, attire l’attention. Je fais aussi attention aux fichiers dont le contenu commence par des éléments incohérents, ou qui chargent du code depuis un chemin étrange.
Trade-off: si ton site a des modifications légitimes (thème enfant, plugin sur mesure, overrides), tu risques de casser quelque chose. L’approche raisonnable consiste à comparer à une version de référence quand elle existe (commit, copie du thème, archive du plugin), ou au moins à lire le fichier suspect et repérer ce qui n’a aucun rôle attendu.
2) Identifier la source de l’injection des champs
Ensuite, je cherche la logique qui ajoute les champs.
Si tu as accès à l’inspecteur du navigateur, tu peux:
- repérer la portion HTML injectée, lire comment la valeur est construite dans le rendu, retrouver le point de contrôle côté PHP (souvent dans un plugin ou un thème).
Sans partir dans des heures de reverse technique, tu peux déjà te poser une question simple: quel plugin est responsable du formulaire ou de la zone où le champ apparaît. Si les champs sont ajoutés “au niveau du formulaire”, je commence par le plugin de formulaire, pas par le thème.
3) Nettoyer la base autour des champs, mais de manière ciblée
Quand je corrige des champs ajoutés par malware, je préfère une suppression ciblée à une “purge générale”. WordPress peut stocker énormément de données, et effacer au hasard peut casser la configuration.
La méthode la plus sûre consiste à identifier les entrées exactes à supprimer, par exemple:
- une option avec une clé précise et une valeur contenant du code suspect, une métadonnée attachée à un contenu précis, avec une valeur incohérente pour ce type de contenu, une entrée liée à un utilisateur compromis.
Si tu as une sauvegarde “avant incident”, la comparaison devient ton meilleur allié. Tu repères les nouvelles clés apparues après la date de l’incident, puis tu analyses leur contenu.
Si tu n’as pas de comparaison temporelle, tu fais l’analyse par contenu et par contexte. Un “nom de clé” et une “valeur” qui contiennent des morceaux de code ou des balises HTML pour une option qui ne devrait pas en contenir, c’est un vrai signal.
Important: ne supprime pas des options “au hasard” juste parce qu’elles existent. Il faut comprendre la logique. Certaines options contiennent des configurations de plugins, et des valeurs encodées peuvent être légitimes.
4) Recréer proprement si nécessaire: préférer une réparation à une chirurgie
Parfois, le plus rationnel n’est pas de supprimer chaque champ un par un. Quand l’incident est étendu, tu peux te retrouver avec des champs multiples, répartis dans plusieurs tables, et une logique injectée qui dépend de plusieurs clés.
Dans ces cas, la stratégie “propre” consiste à:
- restaurer le site à partir d’une sauvegarde saine, appliquer uniquement les correctifs nécessaires (mises à jour, suppression des vecteurs), remettre les contenus manquants si tu as des sauvegardes récentes.
Trade-off: restaurer peut faire perdre des modifications récentes (articles, formulaires, commandes). Mais parfois, c’est plus rapide et moins risqué que de poursuivre une chasse au détail qui dure deux semaines.
Comment être sûr que tu as vraiment corrigé les champs, et pas juste “caché le problème”
Un malware peut revenir par plusieurs voies. Les champs ajoutés peuvent donc réapparaître après une restauration partielle.
Pour valider un nettoyage, je fais un contrôle en trois niveaux.
Contrôle applicatif
Je charge plusieurs pages qui déclenchent le champ, et je vérifie:
- que le champ n’apparaît plus dans le rendu, que les formulaires ne contiennent plus de champs hidden suspects, que le comportement (redirection, tracking, paramètres) revient à la normale.
Je teste aussi avec plusieurs rôles. Un champ peut apparaître uniquement pour un rôle administrateur, par exemple parce qu’il s’agit d’un outil de contrôle pour le malware. Ce détail passe souvent inaperçu si tu ne testes qu’en navigation anonyme.
Contrôle base de données
Je vérifie que les clés ou métadonnées que j’ai supprimées sont bien absentes, ou qu’elles correspondent maintenant à une configuration attendue. Si une clé réapparaît après quelques minutes, c’est presque une preuve que la logique malveillante est encore active.
Contrôle côté fichiers
Je fais un dernier passage sur les fichiers modifiés. Même si tu corriges la base, un fichier encore infecté peut re-générer les champs ou reconfigurer des options.
Les cas “limites” existent. Parfois, un cache ou une minification peut donner l’impression que le champ est encore là, alors qu’il s’agit d’une page générée précédemment. Sur WordPress, je purge les caches de plugins, le cache serveur si possible, et je relance un test en navigation privée.
Les erreurs qui font perdre du temps (et parfois empirent la situation)
Le nettoyage virus WordPress échoue rarement à cause d’un manque d’outils, il échoue souvent pour des raisons humaines et de méthode.
1) Supprimer seulement les fichiers, puis oublier la base. Les champs ajoutés peuvent être stockés en base et réutilisés. 2) Corriger la base, puis oublier un hook en thème ou plugin. La logique malveillante réécrit les champs. 3) Nettoyer sans sauvegarde, ou sauvegarder mais sans pouvoir comparer. Tu te retrouves à “rester prudent”, mais sans preuve. 4) Traiter un symptôme unique alors que la persistance est ailleurs (Cron, compte administrateur révoqué mais pas supprimé, plugin nouvellement installé). 5) Croire qu’un champ “bizarre” est toujours un malware. Certains plugins ajoutent des champs et des métadonnées techniques. La clé, c’est le contenu et la cohérence fonctionnelle.
Si tu veux une boussole pratique, applique ce principe: une correction “sûre” explique pourquoi cette valeur ou ce champ n’a plus de raison d’exister.
Après le nettoyage: renforcer pour éviter que le malware réécrive les champs
Corriger les champs ajoutés, c’est rétablir un état. Renforcer, c’est réduire les chances que quelqu’un ou quelque chose les réinvente.
Je me concentre sur les actions à fort rendement, sans transformer ton site en forteresse impossible à gérer:
- Mettre WordPress, thèmes et plugins à jour, surtout ceux qui étaient présents lors de l’incident. Vérifier les comptes: supprimer les utilisateurs inconnus, forcer des changements de mots de passe, et désactiver les comptes à risque. Mettre en place une politique de mises à jour réaliste (au moins sur les composants critiques). Réduire l’exposition: limiter les plugins, retirer les thèmes inutiles, et supprimer les composants jamais utilisés. Surveiller. Pas besoin de 20 outils, mais au minimum des alertes sur les changements de fichiers et un suivi de la base si ton site a une activité régulière.
Je garde une règle simple: si tu corriges un malware sans renforcer, tu risques de re-croiser exactement le même type de champs ajoutés un peu plus tard. Le vecteur n’a pas disparu.
Mini check final avant de rouvrir en pleine charge
Si tu veux un dernier filtre avant de remettre le site à fond, voici une courte liste de vérification (elle m’a souvent évité des retours en urgence):
- Aucun fichier modifié suspect n’est présent, thèmes et plugins propres. Les options et métadonnées suspectes ne reviennent pas après purge et nouvelle navigation. Les formulaires concernés n’injectent plus de champs cachés inattendus. Les comptes administrateurs sont cohérents et sécurisés. Les pages les plus exposées ne déclenchent plus d’injection conditionnelle.
Quand il faut aller plus loin: cas où les champs sont “propagés” par un plugin
Parfois, le malware n’injecte pas un champ directement. Il modifie un plugin légitime de formulaires pour qu’il ajoute des champs spécifiques. Dans ce cas, même si tu supprimes les valeurs en base, tu gardes une logique modifiée.
Le piège est que l’interface du plugin peut sembler normale. Tu as l’impression que “le formulaire fonctionne”, mais dans le rendu, il ajoute des champs selon des conditions invisibles.
La correction solide consiste à réinstaller le plugin depuis une source fiable, ou à le remplacer par une version saine, puis à nettoyer la base et les paramètres associés. Si tu as une version d’origine (archive, copie du plugin), tu peux comparer les fichiers. Sinon, tu peux remplacer et ensuite analyser la base pour enlever les clés qui ne devraient pas exister.
Je rencontre souvent ce cas sur des sites qui ont installé un plugin de formulaires populaire il y a longtemps, puis l’ont laissé en place malgré des mises à jour manquées. Une vulnérabilité ou un compromis peut se propager sous forme d’un “petit” ajout dans le plugin, et ce petit ajout suffit à des champs injectés.
Réponse rapide à une question fréquente: “peut-on juste supprimer les champs?”
Techniquement, oui, parfois. Mais en pratique, la réponse dépend de la persistance.
- Si le champ injecté dépend uniquement de valeurs en base (et que la logique d’injection a disparu avec les fichiers), supprimer les champs et les options suffit. Si la logique d’injection est encore présente dans un fichier (thème ou plugin), supprimer les champs ne tient que jusqu’à la prochaine exécution. Le champ revient.
Le bon réflexe consiste à combiner: nettoyer les fichiers et nettoyer les données, au minimum là où les champs ont été enregistrés. C’est cette combinaison qui évite le cycle “nettoyage, retour, nouveau nettoyage”.
Si tu veux, décris-moi ce que tu appelles “champs ajoutés” (formulaire sur le front, champs dans l’admin, ou lignes dans une table), et idéalement le type de plugin impliqué ou la zone où tu les observes. Avec ces éléments, je peux te proposer une stratégie de diagnostic plus précise, adaptée à ton cas, sans te faire supprimer des données au hasard.