Site WordPress piraté : nettoyer, remettre en ligne, ne pas rechuter

On découvre rarement un site WordPress piraté en regardant son code. On l’apprend par un client qui signale une redirection vers une boutique douteuse, par un avertissement rouge dans le navigateur, par un courriel de l’hébergeur annonçant une suspension pour envoi de spam, ou par une chute brutale du trafic. Cet article suit l’ordre réel d’une intervention, du constat au durcissement. Et il commence par l’erreur la plus coûteuse : supprimer les fichiers suspects avant d’avoir compris par où l’attaquant est entré.

Confirmer qu’il s’agit bien d’un piratage

Une panne et une intrusion ne se traitent pas de la même façon, et les confondre fait perdre des heures. Cinq signes ne trompent pas :

• Des pages inconnues dans l’index. Une recherche site:votredomaine.fr fait apparaître des titres en langue étrangère ou des pages de contrefaçon que vous n’avez jamais publiées.
• Des redirections conditionnelles. Le site est normal quand vous le visitez directement, mais renvoie ailleurs quand on arrive depuis un moteur de recherche ou depuis un mobile. C’est la signature d’une injection : le code teste l’origine du visiteur avant de se déclencher, ce qui explique que le propriétaire soit le dernier informé.
• Des comptes administrateurs que personne ne reconnaît, souvent créés à des heures nocturnes.
• Des fichiers modifiés récemment alors que rien n’a été publié. Sur un accès SSH, find . -name "*.php" -mtime -7 liste les fichiers PHP touchés dans les sept derniers jours.
• Un envoi massif de courriels depuis le serveur, généralement signalé par l’hébergeur avant que vous ne le remarquiez.

Deux endroits confirment en deux minutes : la rubrique « Problèmes de sécurité » de la Search Console, qui nomme le type d’infection détecté, et les journaux d’accès du serveur, qui donnent l’adresse IP et l’heure des requêtes anormales. Si le site est simplement inaccessible sans aucun de ces signes, vous n’êtes pas piraté : suivez plutôt le protocole des soixante premières minutes.

Les six premières décisions, dans l’ordre

L’ordre compte autant que les actions. Les inverser est la principale cause de récidive.

1. Mettre le site en maintenance plutôt que de le laisser diffuser du contenu malveillant à vos clients et aux moteurs. Chaque heure supplémentaire en ligne aggrave le passage en liste noire.
2. Prévenir l’hébergeur. Il dispose souvent déjà d’éléments : journaux, alertes de son propre scanner, date de la première anomalie. C’est du temps de diagnostic offert.
3. Copier l’état infecté avant tout nettoyage, fichiers et base de données. C’est votre seule preuve exploitable, pour comprendre l’entrée, pour un éventuel dépôt de plainte, et pour retrouver un contenu effacé par erreur pendant le nettoyage.
4. Changer tous les mots de passe depuis un poste sain : administration WordPress, SFTP, base de données, compte d’hébergement, bureau d’enregistrement du domaine, messagerie associée. Si le poste du dirigeant est lui-même compromis, changer les mots de passe depuis ce poste revient à les livrer.
5. Régénérer les clés et sels de sécurité de wp-config.php à partir du générateur officiel de WordPress. Toutes les sessions actives sont invalidées d’un coup, y compris celle de l’attaquant.
6. Ne restaurer une sauvegarde qu’après avoir compris la faille. C’est le point que presque personne n’écrit : restaurer une copie antérieure remet en place la version vulnérable qui a permis l’entrée. Le site est propre le lundi et réinfecté le jeudi.

Nettoyer en profondeur

Une seule idée directrice : le nettoyage se fait par remplacement, jamais par retouche. Retirer une ligne de code malveillante dans un fichier laisse les quinze autres.

Remplacer plutôt que réparer

Réinstallez le cœur de WordPress à partir de l’archive officielle, puis les extensions et le thème depuis leurs sources d’origine, dans les mêmes versions ou plus récentes. Ne conservez que deux choses, toutes deux inspectées : le dossier wp-content/uploads et la base de données. Avec WP-CLI, la vérification préalable prend quelques secondes :

wp core verify-checksums
wp plugin verify-checksums --all
wp core download --force --version=$(wp core version) --locale=fr_FR

Les deux premières commandes comparent vos fichiers aux empreintes publiées par WordPress.org et listent tout ce qui a été modifié ou ajouté. Une extension premium hors dépôt officiel n’est pas couverte : elle se réinstalle depuis le compte de l’éditeur.

Traquer les portes dérobées

Une porte dérobée est un petit fichier qui permet de revenir sans passer par la faille d’origine. Les cachettes habituelles : un fichier PHP déposé dans wp-content/uploads, où il n’y a jamais aucune raison d’en trouver ; le dossier wp-content/mu-plugins, chargé automatiquement et que personne ne regarde ; un thème enfant modifié ; une extension abandonnée depuis deux ans ; une tâche planifiée qui réinstalle le code toutes les nuits ; un compte administrateur dormant. La logique de recherche est toujours la même : comparer aux archives officielles, trier par date de modification, et considérer comme suspect tout ce qui ne s’explique pas.

Nettoyer la base de données

Le code injecté ne vit pas que dans les fichiers. Cherchez les cadres intégrés, les balises de script et les liens ajoutés dans les articles, dans la table des options et dans les widgets. Vérifiez en particulier les options siteurl et home, souvent détournées pour rediriger le site entier. Travaillez sur une copie, gardez la trace de chaque remplacement, et videz tous les caches ensuite : un cache de page conserve la version infectée bien après le nettoyage.

Vérifier ce qui n’appartient pas au site

Le tour de contrôle final, celui que l’on oublie : tâches planifiées inconnues (wp cron event list), comptes SFTP créés récemment, clés SSH ajoutées au serveur, règles de redirection glissées dans .htaccess ou dans la configuration du serveur, et jetons d’application encore valides. Un attaquant sérieux laisse toujours plus d’une porte.

Sortir des listes noires et rassurer les moteurs

La conséquence la plus douloureuse pour une entreprise n’est pas technique : c’est l’écran rouge « Site trompeur » que voient vos clients, et la perte de confiance qui suit. Une fois le nettoyage terminé et vérifié, ouvrez la rubrique « Problèmes de sécurité » de la Search Console, décrivez précisément ce qui a été fait, et demandez un examen. Google indique que ces examens prennent de plusieurs jours à plusieurs semaines, et recommande de ne pas soumettre de nouvelle demande avant la décision : redemander trop tôt allonge le délai (documentation Search Console).

Une demande envoyée avant nettoyage complet est refusée et vous fait perdre une semaine. Vérifiez donc avant d’envoyer : plus aucune page indésirable dans l’index, plus aucune redirection depuis un mobile, plus aucun fichier signalé. Si le serveur a servi à envoyer du spam, contrôlez aussi la réputation d’envoi de votre domaine et de l’adresse IP, et vérifiez que les enregistrements SPF, DKIM et DMARC sont corrects : une messagerie professionnelle qui n’arrive plus à destination est la deuxième vague du sinistre.

L’angle mort : vos obligations quand des données ont fuité

Un site marchand contient des adresses, des commandes et parfois des comptes clients. Un simple formulaire de contact contient déjà des données personnelles. Une intrusion qui a donné accès à ces informations est une violation de données personnelles au sens du RGPD, et elle déclenche des obligations concrètes.

La CNIL doit être notifiée dans les meilleurs délais, si possible dans les 72 heures, dès lors que la violation présente un risque pour les personnes concernées ; un dépassement doit être motivé. Lorsque le risque est élevé, les personnes concernées doivent elles aussi être informées. Dans tous les cas, l’incident doit être documenté en interne : nature de la violation, catégories et nombre approximatif de personnes touchées, conséquences probables, mesures prises (notifier une violation à la CNIL). C’est une raison de plus pour tenir un journal d’intervention dès la première heure.

En parallèle, un dépôt de plainte est possible, et la plateforme publique Cybermalveillance.gouv.fr propose des fiches réflexes et un annuaire de prestataires. Nous ne donnons pas de conseil juridique : nous constatons simplement que les agences web n’abordent presque jamais ce volet, alors que c’est celui qui expose le plus le dirigeant.

Fermer la porte pour de bon

Le nettoyage règle le présent. Ce qui suit règle l’avenir, et ce sont presque toujours les mêmes manques :

• Supprimer, pas désactiver, les extensions et thèmes inutilisés. Une extension désactivée reste sur le serveur et reste exploitable.
• Double authentification sur tous les comptes administrateurs, et limitation des tentatives de connexion pour éteindre la force brute.
• Droits de fichiers corrects : 644 pour les fichiers, 755 pour les dossiers, et un wp-config.php plus restrictif encore. Un dossier en 777 est une invitation.
• Édition de fichiers désactivée depuis l’administration, avec define( 'DISALLOW_FILE_EDIT', true ); : un compte administrateur volé ne donne plus l’accès direct au code du thème.
• Filtrage en amont par un pare-feu applicatif, pour que les requêtes malveillantes n’atteignent jamais PHP. Un service en périphérie permet de filtrer les requêtes avant qu’elles n’atteignent le site, quel que soit l’hébergement.
• Mises à jour appliquées vite. Entre la publication d’un correctif et son exploitation automatisée, il s’écoule souvent moins d’une semaine.

Le détail de ces mesures est développé dans les mesures de sécurité essentielles et dans notre guide pas à pas pour sécuriser WordPress.

Notre position : combien de temps, et à quel moment déléguer

Nous donnons des durées, jamais de forfait à l’aveugle : un site vitrine correctement sauvegardé se nettoie en quelques heures ; un site marchand sans sauvegarde saine demande une à deux journées, l’essentiel du temps passant à chercher les portes dérobées et à revalider les commandes. Trois situations justifient de déléguer sans hésiter : aucune sauvegarde antérieure à l’infection, un piratage qui revient après un premier nettoyage, ou une boutique en activité, où chaque heure de fermeture se compte en commandes perdues.

Notre position est simple : nous refusons de nettoyer un site sans en corriger la cause. Un nettoyage seul est un service qui se revend tous les deux mois, et nous ne voulons pas de ce modèle. Une intervention et nettoyage par tickets se déroule toujours dans le même ordre : constat écrit, copie de l’état infecté, nettoyage par remplacement, durcissement, demande d’examen aux moteurs, puis rapport indiquant la faille identifiée et les mesures appliquées. Sans ce dernier point, l’intervention n’est pas terminée.

Après le nettoyage vient la prévention : c’est le rôle d’un suivi WordPress mensuel.

Conclusion

Un site piraté n’est pas un site mal aimé, c’est un site mal entretenu. Les attaques sont automatiques, elles ne visent personne en particulier, et elles trouvent toujours la même chose : une extension oubliée, un mot de passe réutilisé, une version de PHP dépassée. Le nettoyage règle le présent ; seule la maintenance règle l’avenir. Si vous avez un doute sur l’état de votre site aujourd’hui, commencez par la rubrique « Problèmes de sécurité » de la Search Console : c’est gratuit et cela prend deux minutes.

Faire nettoyer mon site Parler de la sécurité de mon site