Le site s’affiche normalement. Les pages sont à jour, aucune alerte nulle part, le client n’a rien remarqué. Puis quelqu’un tape le nom de l’entreprise dans Google et tombe sur un résultat qui parle de Viagra, de Cialis ou de pharmacie en ligne, avec l’adresse du site en dessous. C’est le pharma hack : la compromission la plus rentable pour l’attaquant, et la plus humiliante pour le propriétaire du site, parce qu’elle est invisible depuis le site lui-même.

Ce qu’est réellement le pharma hack

Il ne s’agit ni d’un défacement, ni d’un rançongiciel. L’attaquant ne veut pas casser le site : il veut l’emprunter. Votre domaine a une ancienneté, des liens entrants, une réputation auprès de Google — trois choses qui coûtent cher à fabriquer. Le pharma hack consiste à greffer sur ce capital des milliers de pages de spam pharmaceutique qui se positionnent dans les résultats de recherche et renvoient le visiteur vers des officines en ligne. Vous payez l’hébergement et la réputation, quelqu’un d’autre encaisse le trafic.

La conséquence n’est pas cosmétique. Google finit par signaler le site comme compromis dans la Search Console, affiche un avertissement aux internautes, puis désindexe. Les positions construites en plusieurs années s’effondrent en quelques jours, et la remise en confiance prend des semaines — bien plus longtemps que le nettoyage technique lui-même.

Pourquoi vous ne le voyez pas

Parce que le code sait qui le regarde. C’est ce qu’on appelle le cloaking : le site sert une version aux robots d’indexation et une autre aux humains. Concrètement, le code injecté examine l’en-tête User-Agent, parfois l’adresse IP ou le site d’où vient le visiteur, puis décide.

Googlebot reçoit une page complète, bien structurée, bourrée de mots-clés pharmaceutiques et de liens sortants.
Un visiteur ordinaire reçoit une erreur 404, une redirection vers le site marchand, ou la page normale du site — selon ce qui attire le moins l’attention.
L’administrateur connecté ne voit jamais rien : beaucoup de charges utiles se désactivent dès qu’un cookie de session WordPress est présent.

D’où une règle simple : un site propre en apparence n’est pas un site propre. Tant que l’on n’a pas regardé le site avec les yeux de Google, on n’a rien vérifié du tout.

Les cinq contrôles qui révèlent l’infection

Aucun ne demande d’outil payant, et tous se font en dix minutes.

La recherche site: dans Google, tapez site:votredomaine.fr viagra, puis la même chose avec cialis, pharmacy, pills. Un seul résultat suffit à confirmer.
Le nombre de pages indexées : site:votredomaine.fr sans autre terme. Si un site de 40 pages en annonce 4 000, la question est réglée.
La Search Console : onglet Sécurité et actions manuelles, mais aussi la liste des pages indexées, le rapport de couverture — et surtout la liste des utilisateurs ayant accès à la propriété, où les attaquants s’ajoutent volontiers pour soumettre leurs propres sitemaps.
Les sitemaps : ouvrez le fichier d’index et déroulez-le. Un sitemap que personne n’a créé, ou une liste d’URL inconnues, ne laisse aucun doute.
La vue Googlebot : consultez une URL suspecte en changeant l’agent utilisateur du navigateur pour celui de Googlebot (outils de développement, onglet Réseau). La page de spam apparaît alors que la même URL renvoie 404 en navigation normale.

Où le code se cache

Le pharma hack est rarement un fichier unique. Il est modulaire, redondant, et prévu pour se réinstaller. Les emplacements qui reviennent le plus souvent :

Les fichiers de tête : index.php, wp-config.php, wp-settings.php, avec quelques lignes ajoutées tout en haut ou tout en bas, souvent après des centaines d’espaces pour passer inaperçues.
Plusieurs .htaccess, dont certains dans des sous-dossiers où il n’y en a jamais eu : ils pilotent les redirections conditionnelles.
La base de données : contenus injectés directement dans wp_posts (pages publiées, souvent antidatées), et surtout wp_options, qui héberge des options d’apparence anodine contenant du code encodé.
Les tâches planifiées : une entrée cron qui réécrit les fichiers nettoyés quelques heures après votre passage. C’est la raison numéro un des « réinfections » signalées deux jours plus tard.
Le dossier uploads : aucun fichier .php n’a rien à y faire. Leur présence est un signal à elle seule.
Les thèmes et extensions inactifs, jamais mis à jour puisque jamais utilisés, et donc parfaits pour héberger une porte dérobée.

Le code lui-même est obscurci : eval, base64_decode, gzinflate, concaténations de variables, et de plus en plus souvent des caractères Unicode qui ressemblent à des caractères latins pour tromper une recherche textuelle. Chercher eval( ne suffit plus ; il faut comparer les fichiers à leur version officielle.

Le nettoyage, dans l’ordre

L’ordre compte autant que les gestes. Nettoyer les fichiers avant d’avoir coupé les accès revient à repeindre pendant que la fenêtre est ouverte.

1. Figer la situation

Sauvegarder l’état infecté — fichiers et base — avant toute intervention. C’est la seule pièce qui permettra de comprendre par où l’attaquant est entré, et de vérifier plus tard qu’on n’a rien oublié. Ensuite seulement, couper : mots de passe de tous les comptes, accès FTP/SFTP, base de données, panneau d’hébergement, et régénération des clés de sécurité de wp-config.php pour invalider les sessions ouvertes.

2. Remplacer plutôt que réparer

Le cœur de WordPress se remplace intégralement par une archive officielle de la même version : wp-admin et wp-includes écrasés, fichiers racine remplacés à l’exception de wp-config.php et du dossier wp-content. Pour les extensions et les thèmes, on réinstalle depuis la source officielle au lieu de corriger ligne à ligne. Seul le thème sur-mesure demande une comparaison manuelle avec le dépôt de code.

3. Traiter la base et les relances

Supprimer les contenus injectés dans wp_posts, inspecter wp_options, vider les tâches planifiées illégitimes, supprimer les comptes administrateur non identifiés — et vérifier les adresses de messagerie des comptes restants, souvent modifiées en douce pour récupérer les liens de réinitialisation.

4. Vérifier comme un robot, pas comme un humain

On refait les cinq contrôles du début, en agent utilisateur Googlebot, et on les refait encore trois jours plus tard. Un pharma hack déclaré propre au bout d’une heure est un pharma hack qu’on n’a pas fini de nettoyer.

Le volet SEO, celui qu’on oublie toujours

Le site peut être parfaitement assaini et continuer à afficher des résultats pharmaceutiques pendant des semaines : l’index de Google, lui, n’a pas été nettoyé. Quatre gestes s’imposent une fois le site sain :

Faire retourner un code 410 (ou 404) sur les URL de spam, plutôt que de les rediriger vers l’accueil.
Régénérer et resoumettre le sitemap légitime, supprimer tout sitemap étranger déclaré dans la Search Console.
Demander un examen de sécurité dans la Search Console, en décrivant ce qui a été fait — un dossier précis est traité plus vite.
Surveiller le nombre de pages indexées pendant un mois : c’est l’indicateur qui confirme la guérison, pas le scanner.

Par où ça entre

Trois portes, presque toujours les mêmes : une extension ou un thème non mis à jour comportant une faille connue ; une extension ou un thème « nulled », téléchargée gratuitement alors qu’elle est payante, et livrée avec sa porte dérobée intégrée ; ou, de plus en plus, un identifiant d’administration volé ailleurs et rejoué sur le site, sans la moindre tentative échouée dans les journaux.

Les deux premières se règlent par de la discipline de maintenance. La troisième ne se règle que par la double authentification et l’hygiène des accès.

Comment nous intervenons

Nous traitons ces situations comme des reprises de site, pas comme des dépannages. L’ordre de nos interventions est toujours le même : constater avec les bons outils, figer l’état, couper les accès, remplacer le code par des sources officielles, nettoyer la base, puis rouvrir — et enfin travailler l’index côté moteur de recherche, qui est la partie visible pour le client.

Sur les sites que nous maintenons, l’essentiel du travail est fait en amont : inventaire des extensions et suppression de celles que plus personne n’utilise, aucune source non officielle, comptes nominatifs et rôles minimaux, second facteur sur les accès à privilèges, durcissement de l’installation, mises à jour suivies, et sauvegardes assez anciennes pour couvrir une infection qui daterait de plusieurs semaines. Ce sont les mêmes réflexes que ceux décrits dans nos missions de développement et de maintenance WordPress, de reprise de site et de référencement.

À faire aujourd’hui, même si tout va bien

Tapez site:votredomaine.fr dans Google et comparez le nombre de résultats au nombre de pages que vous pensez avoir. Ouvrez la liste des utilisateurs de votre Search Console. Ouvrez celle des extensions installées. Trois minutes, et vous saurez si le sujet vous concerne.

Si quelque chose cloche, ou si vous préférez faire regarder par quelqu’un dont c’est le métier : écrivez-nous. Nous commençons toujours par un état des lieux, avant de toucher à quoi que ce soit.

Sécurité

Pharma hack : quand votre site vend des médicaments à Google