Supprimer malware WordPress : nettoyer header.php et footer.php compromis

Quand un site WordPress est compromis, ce n’est pas seulement une histoire de “fichier infecté”. C’est souvent une chaîne de décisions prises à la minute où l’attaquant a eu accès, puis une série d’appels discrets déclenchés à chaque chargement de page. Dans la pratique, si vous voyez des redirections, des scripts inconnus, ou du contenu qui change sans raison, deux fichiers reviennent très souvent dans l’enquête: header.php et footer.php. Parce que ce sont les endroits parfaits pour injecter du code dans le front-end, avant ou après le rendu.

Ce qui suit n’est pas une liste de promesses. C’est la manière réaliste de procéder quand on doit supprimer malware WordPress, repartir sur une base saine, et éviter le piège classique du “on a effacé une ligne, mais l’infection continue”.
Pourquoi header.php et footer.php sont des cibles privilégiées
Dans WordPress, header.php et footer.php servent à structurer presque toutes les pages. Ils appellent le wp_head(), gèrent les balises, chargent des scripts, et ferment la structure HTML. Même un ajout minuscule, placé au bon endroit, peut suffire à:
charger un script externe (ou modifié), déclencher une redirection conditionnelle, voler des données via une requête discrète, ou servir une charge utile seulement pour certains navigateurs, pays, ou pages.
Ce type d’infection est souvent “intermittent”. Par exemple, vous testez votre site depuis votre poste, tout semble normal. Puis un visiteur sur mobile, ou une IP différente, voit une redirection vers une page de publicité. Vous ne le voyez pas, parce que le code peut tester des conditions avant d’agir. C’est pour ça que l’analyse du contenu de header.php et footer.php doit être faite avec méthode, sans se limiter aux apparences.

Je me souviens d’un cas concret: un site e-commerce, un trafic stable, aucun pic côté serveur, et pourtant des pages “produit” redirigeaient aléatoirement. Le code malveillant était dans footer.php, mais camouflé dans une longue chaîne de caractères base64. Au premier regard, le fichier ressemblait à un mix de HTML normal et de PHP “un peu sale”. La suppression directe ne suffisait pas: il fallait aussi nettoyer les éléments associés, puis vérifier que l’attaque ne s’appuyait pas sur un chargement ultérieur via un fichier déjà présent ailleurs.
Les signes qui orientent vers une compromission de fichiers de thème
On ne fait pas de diagnostic à l’aveugle. Plusieurs signaux reviennent dans les incidents réels:
des scripts qui apparaissent dans le navigateur mais ne sont pas dans vos médias, pas dans vos plugins, ni dans votre thème, une modification du DOM après chargement, des redirections sur certaines URLs (par exemple vers *.ru ou une landing “scan”), une différence entre ce que vous voyez en public et ce que vous voyez en mode éditeur, ou connecté en admin, des alertes de sécurité dans des navigateurs, des outils de recherche, ou des scanners hébergés par le provider.
Un détail important: si header.php et footer.php sont touchés, c’est parfois seulement la partie visible. L’attaquant peut injecter un appel vers un fichier dans wp-content/uploads/ ou dans un sous-dossier d’un thème. D’où l’intérêt de lire attentivement, pas seulement de “supprimer ce qui a l’air suspect”.
Préparer le nettoyage: sauvegarder et figer l’environnement
Avant d’ouvrir les fichiers, l’objectif est simple: éviter d’empirer la situation pendant l’effacement.

Commencez par une sauvegarde propre, même si vous pensez déjà tout connaître. Une sauvegarde “brute” (copie de l’arborescence) et un export de base de données peuvent suffire, à condition de pouvoir revenir en arrière rapidement. Si vous n’avez pas de sauvegarde récente, faites au minimum une copie des fichiers de thème concernés et des endroits probables (d’abord wp-content/themes/<votre-theme>/, puis, selon le contexte, wp-content/plugins/).

Ensuite, “figez” si possible:
mettez le site en maintenance, désactivez temporairement les caches serveur et CDN qui pourraient brouiller vos tests, coupez l’accès public si la redirection est active et dangereuse.
Ce n’est pas une étape romantique, mais elle évite des scénarios où des internautes continuent à être redirigés pendant que vous corrigez un fichier. Et, surtout, elle vous laisse du temps pour reproduire le comportement sur une page test avant et après.
Repérer le code injecté dans header.php
Ouvrez wp-content/themes/<theme>/header.php et cherchez des indicateurs. Je ne parle pas de “tout ce qui ressemble à du PHP”. Dans un thème, on trouve forcément des conditions, des fonctions, des appels. La suspicion vise plutôt la structure du code ajouté.

Soyez attentif aux éléments suivants dans header.php:
appels à base64_decode, gzinflate, str_rot13, ou concaténations qui reconstituent du code, balises script injectées depuis des URLs non annoncées dans vos réglages, conditions “bizarres” autour de $_SERVER, du user agent, ou de certaines variables qui filtrent les visiteurs, fonctions qui exécutent autre chose que ce que vous utilisez normalement (par exemple eval ou assert dans le PHP, ou du JavaScript “minifié” injecté sans justification), commentaires ou morceaux de code qui ne ressemblent pas au style du thème d’origine.
Le point clé: si vous trouvez un bloc qui ressemble à un “chargeur” plutôt qu’à une partie de votre mise en page, vous devez comprendre ce qu’il fait avant de le supprimer. Une suppression au hasard peut casser votre rendu, mais elle peut aussi laisser derrière elle une partie qui continue de s’exécuter ailleurs.
Un piège fréquent: le code dans header.php mais l’action ailleurs
Il arrive très souvent que header.php ne contienne pas la “charge finale”. Elle appelle plutôt un fichier externe ou interne, par exemple en chargeant un script via <script src="...">. Parfois, cette ressource n’existe pas au premier coup d’œil, parce qu’elle est générée, renommée, ou stockée sous un nom aléatoire.

Dans ce cas, notez précisément l’URL ou le chemin. Ensuite, vérifiez si le fichier ciblé existe réellement dans votre WordPress. S’il est dans wp-content/uploads/ ou dans un dossier de thème inattendu, ne vous contentez pas de supprimer l’injection du header. Il faut aussi enlever la ressource et vérifier son existence dans les autres points du site.
Repérer le code injecté dans footer.php
footer.php est encore plus “pratique” pour l’attaquant, car beaucoup de scripts à effet tardif se chargent à la fin de la https://gardewp.fr/ https://gardewp.fr/ page. Là, le malware peut:
déclencher une redirection après un délai, enregistrer un script avec une requête vers un serveur externe, afficher des iframes ou des overlays, ou exécuter un code qui n’est pas évident à la lecture rapide.
À l’ouverture de footer.php, cherchez des motifs qui ne cadrent pas avec un footer “normal”. Quelques exemples concrets observés dans des incidents réels:
un bloc PHP qui insère du <script> à la volée, une chaîne codée puis décodée, des conditions qui testent des variables de contexte avant d’agir, des redirections basées sur des comparaisons de chaînes de l’URL.
Je vous conseille aussi une méthode “diff”. Si vous gardez une copie du thème avant incident, comparez header.php et footer.php avec la version saine. Sans forcément être outillé, vous pouvez au moins repérer les blocs ajoutés en fin de fichier ou au milieu, là où le thème d’origine ne les aurait pas mis.
Supprimer malware WordPress: nettoyer sans casser votre thème
Une fois que vous avez identifié le bloc malveillant, la tentation est de le supprimer directement. C’est parfois correct, mais dans l’expérience, il y a trois cas.

Premier cas: vous avez un petit bloc injecté, isolé, qui n’appelle rien d’autre. Dans ce scénario, supprimer le bloc est souvent suffisant, à condition de vérifier que les dépendances ne restent pas.

Deuxième cas: vous avez un bloc injecté qui charge une ressource externe ou un fichier local. Là, supprimer le bloc peut stopper l’appel, mais le fichier malveillant reste sur le serveur. À court terme, c’est mieux. À moyen terme, ça demeure un risque, surtout si d’autres chemins dans le code réappellent cette ressource, ou si d’autres pages ont aussi été modifiées.

Troisième cas: votre thème ou plusieurs fichiers ont été modifiés, et le malware a laissé des hooks, des filtres, ou des ajouts à des fichiers partagés (par exemple un functions.php, un fichier d’un constructeur de thème, ou même une inclusion depuis wp-config.php). Dans ce cas, nettoyer uniquement header.php et footer.php peut réduire l’impact, mais pas éliminer la cause.

La règle pratique: après le nettoyage de header.php et footer.php, vérifiez le reste du thème, puis réinitialisez les fichiers de thème à une version saine si vous pouvez. La méthode la plus fiable, quand vous avez accès aux sources du thème, c’est de remplacer les fichiers du thème par la version d’origine ou une version saine publiée.

Si le thème est sur mesure et que vous n’avez pas la base, il faut faire preuve de jugement: ne supprimez pas du code utile. Mais vous pouvez au moins restaurer header.php et footer.php depuis une version connue, si elle existe. Sinon, supprimez uniquement les blocs clairement injectés, et gardez le reste tel quel.
Vérifier les dépendances: scripts externes, fichiers ajoutés, variables
Le nettoyage efficace ne s’arrête pas au fichier modifié. Quand je fais ce type d’intervention, je vérifie systématiquement trois choses.

D’abord, les URLs injectées. Si votre navigateur montre des requêtes vers un domaine inconnu, identifiez l’origine dans header.php ou footer.php. Puis cherchez dans l’arborescence si ce domaine correspond à un appel à un fichier existant chez vous, ou si c’est un chargement externe. Même si le chargement externe a été coupé, il faut supprimer les éléments responsables dans vos fichiers.

Ensuite, l’apparition de fichiers nouveaux. Un malware qui s’injecte dans un thème a souvent aussi déposé des fichiers dans wp-content/uploads/, dans un sous-dossier d’un thème, ou parfois dans wp-content/ à des endroits non attendus. Vérifiez les dates de modification et la taille des fichiers. Les charges “légères” peuvent faire quelques kilo-octets. Les charges “bruyantes” peuvent être plus grandes, mais ça varie.

Enfin, les hooks WordPress. Un code peut être injecté via des actions ou des filtres, par exemple en ajoutant un add_action dans un endroit inattendu. Même si l’attaquant a commencé dans header.php ou footer.php, il est parfois allé plus loin.
Une checklist courte, mais utile
Avant de valider que vous avez vraiment supprimé malware WordPress, je recommande de passer par un petit contrôle.
Remplacez ou nettoyez header.php et footer.php uniquement après avoir noté les blocs suspects et leur logique (ce qu’ils appellent, ce qu’ils déclenchent). Recherchez dans tout le thème les occurrences de fonctions typiques de décodage (comme base64_decode) et de redirections (comme wp_redirect ou des assignments de window.location côté JavaScript). Vérifiez wp-content/uploads/ et les sous-dossiers des thèmes/plugins pour tout fichier récemment créé ou modifié. Contrôlez la source des scripts dans votre navigateur, onglet réseau, et confirmez qu’aucune requête inconnue n’apparaît sur les pages test. Si vous avez un accès au thème “d’origine”, remplacez les fichiers du thème par une version saine, plutôt que de patcher au fil de l’eau.
C’est court, mais c’est ce qui fait gagner du temps quand vous êtes en mode incident.
Réinfection: comment ça arrive, et comment la prévenir
Le scénario le plus frustrant, c’est “on a nettoyé”, puis deux jours après ça revient. Dans les cas récurrents, ce n’est pas que vous avez fait une erreur de nettoyage, c’est que la porte d’entrée reste ouverte.

Les causes classiques:
identifiants compromis (un compte admin créé par l’attaquant, ou une session persistante), plugin vulnérable ou obsolète, fichier modifié qui continue à déposer du code via un appel à un autre fichier, thème ou plugin non remplacé intégralement, donc le malware a survécu dans un autre fichier, accès serveur, clés API, ou intégration tiers compromise.
Le nettoyage de header.php et footer.php traite l’exécution front-end, mais la “racine” peut être ailleurs. C’est pour ça que je traite ces fichiers comme un point d’entrée probable, pas comme l’unique cible.
Exemple de démarche sur un cas réel (sans théâtre)
Sur un site où footer.php était modifié, le code injecté ne ressemblait pas à un script complet. C’était un petit bloc qui insérait un script depuis un nom de fichier long et peu lisible. En inspectant la page, on voyait une requête XHR vers un domaine qui n’avait rien à faire là.

Le premier mouvement a été de supprimer ce bloc injecté. Au bout de quelques minutes, le site semblait “redevenir normal”. Puis un autre test sur une page spécifique a montré une redirection qui ne venait pas du footer, mais d’un autre point d’entrée. On a alors découvert un autre fichier du thème modifié, inclus dans certaines pages uniquement. La correction correcte a été de restaurer tout le thème, pas seulement les deux fichiers.

Ce type d’histoire explique pourquoi je insiste sur la logique “dépendances + restauration”. Vous voulez arrêter l’exécution, puis revenir à une base propre.
Quand remplacer le thème est plus sûr que réparer au stylo
Si votre thème est issu d’un dépôt officiel ou d’un package que vous pouvez obtenir, remplacer est souvent le meilleur compromis. Réparer à l’aveugle peut laisser des miettes.

En revanche, si le thème est fortement custom, remplacer peut coûter du temps et provoquer des régressions. Dans ce cas, la meilleure approche est d’identifier précisément les sections modifiées, puis de restaurer celles qui ne devraient pas l’être. Cela demande une comparaison avec une version saine, ou au moins une connaissance du contenu normal des fichiers.

Le jugement vient de l’écart. Si header.php contient des blocs qui n’ont aucune logique “thème”, ou si footer.php injecte un script qui n’est ni dans vos réglages, ni dans votre charte, je privilégie la restauration et la suppression totale des ajouts, plutôt que la correction partielle.
Tester après nettoyage: méthode et prudence
Après correction, ne vous contentez pas d’un chargement dans un onglet. Faites au moins deux types de tests:
Test “navigateur”: onglet réseau pour voir les scripts chargés et repérer toute requête externe non attendue. Test “pages variées”: page d’accueil, page produit ou article, page qui déclenche des templates différents (et parfois page de connexion si possible).
Si le malware est conditionnel, il peut s’activer seulement sur certaines URL ou selon le user agent. Idéalement, testez depuis un autre navigateur, ou via une session non connectée. Sinon, vous pourriez croire que c’est propre alors qu’un comportement malveillant existe pour les visiteurs anonymes.

Une précaution utile: si un cache CDN est en place, il peut masquer la correction pendant un moment. Le nettoyage peut être bon, mais vous ne le verrez pas tout de suite. Dans ces cas, purgez le cache, ou testez directement en mode “désactivation de cache” côté navigateur.
Verrouiller après l’incident: limiter les récidives
Une fois le site nettoyé, vous devez réduire les chances qu’un attaquant revienne.

C’est là que les actions “banales” comptent énormément: mise à jour de plugins et du thème, suppression des plugins inactifs, rotation des mots de passe, retrait des comptes inconnus, et revue des utilisateurs. Si vous avez des symptômes persistants, je regarde aussi les fichiers récemment modifiés hors des thèmes, et je contrôle les règles de déploiement ou d’intégration automatisée.

Si vous utilisez un thème builder ou un plugin de type formulaire avec des intégrations externes, gardez à l’esprit que vous pouvez avoir des scripts légitimes qui se ressemblent. Le but n’est pas de casser toutes les dépendances externes, c’est de ne garder que celles qui sont justifiées, versionnées, et attendues.
Conclusion technique qui n’en dit pas plus que nécessaire
Nettoyer header.php et footer.php compromis est souvent l’étape la plus visible pour supprimer malware WordPress, surtout quand l’injection passe par le front-end. Mais l’expérience montre que réussir, c’est enchaîner trois choses: identifier la logique réelle du code malveillant, éliminer aussi ses dépendances, puis revenir à une base saine en restaurant le thème ou les fichiers touchés.

Si vous voulez, décrivez-moi ce que vous voyez dans vos header.php et footer.php (sans données sensibles, en masquant les domaines et jetons). Je peux vous aider à repérer le type d’injection, les dépendances probables, et la meilleure stratégie entre suppression ciblée et restauration complète.