Quand un site WordPress commence à “agir bizarrement”, on cherche souvent la faille dans un plugin. C’est logique, parce que les plugins exposent plus de surface. Pourtant, dans les incidents que j’ai eu à traiter, le thème arrive régulièrement au premier plan, surtout quand l’infection a été intégrée discrètement dans des fichiers “sans importance” du point de vue fonctionnel: functions.php, des fichiers inclus conditionnellement, ou même un template dont personne ne regarde le contenu après une mise à jour.
L’objectif de l’audit du thème n’est pas seulement de “trouver du code”. Il s’agit de vérifier qu’aucune exécution inattendue ne peut se produire, de comprendre comment le code serait déclenché, et d’évaluer l’ampleur réelle de la compromission. Un thème peut servir de vecteur, soit parce qu’il contient directement la charge malveillante, soit parce qu’il sert de passerelle pour charger du code à distance, modifier des pages, piéger une session, ou exfiltrer des données.
Ce guide détaille une méthode d’audit réaliste, centrée sur le thème, avec des techniques de détection qui marchent aussi quand l’infection est volontairement “cachée”. Je parle de ce que vous pouvez vérifier concrètement, et aussi des angles morts à connaître, car un audit “trop confiant” peut faire perdre du temps à la remédiation.
Comprendre ce que le thème peut faire en cas d’infection
Un thème WordPress a des points de contact très pratiques. Sans même parler de fichiers que l’on ne modifie jamais, il peut:
- s’exécuter à chaque chargement via functions.php et certains hooks, inclure des fichiers additionnels selon des conditions, altérer la sortie HTML ou JavaScript rendu côté navigateur, manipuler des actions sur wp_enqueue_scripts, template_redirect, init, et autres hooks fréquents.
Un code malveillant dans le thème cherche généralement une de ces trois cibles: persistance, déclenchement furtif, et impact en aval. Persistance veut dire que le code survit aux actions habituelles (mise à jour des pages, navigation standard). Déclenchement furtif signifie qu’il ne se manifeste pas forcément pour tous les visiteurs, ou seulement dans des conditions précises (user-agent, pays, heure, cookies, présence d’une requête particulière). Impact en aval, c’est quand le thème modifie des formulaires, détourne des formulaires vers un endpoint externe, ajoute des scripts, ou provoque une redirection.
Ce cadre aide à lire le thème avec un bon état d’esprit. On n’inspecte pas “pour voir si c’est suspect”, on cherche des comportements: chargements inattendus, exécution conditionnelle, et transformations anormales.
Avant d’ouvrir les fichiers: sécuriser le terrain
Avant de toucher quoi que ce soit, mon conseil est simple: travaillez sur une copie. Un thème infecté peut déclencher des appels réseau au moment où vous l’analysez, par exemple via du code exécuté lors d’un chargement PHP. Si vous avez un environnement de test, clonez le site, puis analysez depuis ce clone.
Il y a aussi un risque pratique: si vous cherchez à “nettoyer” en supprimant du code, vous pouvez casser le thème et perdre la capacité d’afficher certaines pages, ce qui complique la restitution. Un audit propre commence donc par:
- une copie de sauvegarde complète, une observation rapide des symptômes (pages qui changent, scripts externes apparents, trafic anormal), un relevé de ce qui a été modifié récemment (dates, utilisateurs ayant mis à jour des thèmes).
Dans un incident typique, j’ai déjà vu un thème “qu’on n’avait pas mis à jour depuis des mois” et pourtant des fichiers dataient de la veille. Ce détail ne prouve pas tout, mais il est un signal très fort que la compromission n’est pas ancienne.
Repérer les fichiers à inspecter en priorité
Le thème contient parfois beaucoup de dossiers et de templates. L’astuce est de ne pas partir de l’ensemble, mais des endroits qui déclenchent l’exécution.
Commencez par:
- functions.php fichiers qui incluent des scripts externes via wp_enqueue_scripts ou qui modifient le HTML templates utilisés sur les pages “accueils” ou “comptes” si vous avez observé des changements visibles fichiers auxiliaires chargés dynamiquement (souvent via require ou include depuis functions.php)
Ensuite, élargissez. Les injections malveillantes se cachent parfois dans des fichiers “d’apparence banale”, comme un utilitaire de thème, un fichier de traduction, ou une fonction “widget” qui n’est pas activée en production. Le problème, c’est qu’un code malveillant peut activer le comportement uniquement dans certains cas, donc le fait que la fonctionnalité ne soit pas utilisée ne garantit rien.
Dans votre audit, conservez un inventaire simple: fichier, taille, date de modification, et présence de code PHP inhabituel. Un fichier qui fait 200 Ko ou 400 Ko alors que ses voisins font quelques dizaines de Ko est souvent un bon candidat. Inversement, une charge malveillante peut être très petite si elle sert juste de “loader” et que le vrai code est récupéré ailleurs.
Les signaux typiques dans un thème infecté
L’infection n’est pas toujours bruyante. Beaucoup d’attaques utilisent des mécanismes de “camouflage” dans le but de contourner une lecture rapide.
Voici les marqueurs que je vérifie presque systématiquement lors d’un audit de thème. Je les donne ici en termes de comportement, pas seulement de mots-clés.
Un code suspect peut:
Exécuter du contenu “transformé” à la volée, par exemple en décodant une chaîne encodée puis en l’évaluant en PHP. Utiliser des fonctions de transformation ou exécution dynamique de manière répétée et non justifiée par le thème. Contenir des URL ou des IP, surtout si elles apparaissent dans des blocs conditionnels (et pas uniquement dans un tableau de variables statiques). Injecter du JavaScript ou des balises