Mes visiteurs voient une fausse page « prouvez que vous êtes humain »

Vous ne voyez rien, et pourtant ils ont raison

Un client vous écrit qu’avant d’arriver sur votre boutique, il a vu une page de vérification lui annonçant un trafic web inhabituel, avec un message du type « Unusual Web Traffic Detected », et lui demandant d’effectuer une manipulation sur son propre ordinateur pour prouver qu’il n’est pas un robot. Vous ouvrez votre site : rien. Vous rechargez : rien. Vous testez sur deux autres pages : toujours rien. La tentation est grande de conclure que le client s’est trompé de site, ou qu’il a une extension de navigateur douteuse.

C’est presque toujours faux. Le code est bien sur votre serveur. Ce qui change, c’est qu’il ne se déclenche pas pour tout le monde. Un code injecté dans un thème peut décider, à chaque affichage, de servir la page normale ou la page piégée, en fonction de ce qu’il apprend du visiteur : son navigateur, son système, la provenance de sa visite, le fait qu’il soit connecté ou non à l’administration. Je ne peux pas vous dire quels critères précis retient telle ou telle variante — cela change d’une campagne à l’autre — mais le principe est constant : le propriétaire du site, qui arrive toujours par le même chemin, avec la même session et le même navigateur, est le visiteur le moins susceptible de voir quoi que ce soit.

C’est aussi ce qui rend ces infections durables. Tant que personne ne reproduit les conditions d’un vrai visiteur, le site paraît sain depuis le back-office, et le problème reste dans les messages du service client.

Où se cache le code, et pourquoi tous les thèmes sont concernés

Sucuri a documenté en mai 2025 une campagne exactement conforme à ce que vos clients décrivent. Le code malveillant est injecté dans le fichier header.php de tous les thèmes installés, et non du seul thème actif. Il renvoie vers un fichier verification.html déposé sur le serveur, qui contient la fausse page de vérification. Le visiteur y lit qu’un trafic inhabituel a été détecté et qu’il doit exécuter une manipulation sur sa machine. S’il la suit, il installe un logiciel malveillant sur son ordinateur. Il s’agit d’une évolution d’une campagne déjà observée par Sucuri en mars 2025.

Le point important à comprendre est celui-là : dans ce schéma, la victime finale n’est pas votre serveur. Votre site n’est pas volé, il n’est pas chiffré, ses données ne partent pas forcément. Il sert de point de distribution. C’est ce qui explique le décalage entre ce que vous mesurez — un site qui répond normalement, des commandes qui passent — et ce que vos clients vivent.

Le détail des « tous les thèmes installés » n’est pas une précision de curiosité. Un thème que vous n’utilisez pas, laissé en place après un essai ou livré par défaut avec l’installation, reste un fichier PHP présent sur le serveur. Le nettoyer uniquement sur le thème actif laisse le reste du code en place, prêt à être rappelé si le thème change, et laisse surtout croire que le problème est réglé. Je pars donc toujours du principe qu’il faut inspecter l’intégralité du dossier des thèmes.

Il faut aussi vérifier une deuxième cachette. Le dossier wp-content/mu-plugins/ contient les extensions dites « must-use » : elles sont chargées automatiquement à chaque affichage de page, sans activation, et n’apparaissent pas dans la liste des extensions du tableau de bord. Un site audité uniquement depuis l’interface d’administration a donc un angle mort complet à cet endroit.