WordPress piraté : nettoyage et sécurisation pas à pas

Un site WordPress piraté impose une logique de crise : il faut agir vite, mais dans le bon ordre. C’est le point le plus important. Se précipiter pour « réparer » un site en production, réinstaller des extensions au hasard ou restaurer une vieille sauvegarde sans contrôle peut détruire des preuves, laisser une porte dérobée en place ou réinjecter l’infection. Wordfence recommande d’agir rapidement, tout en évitant notamment de restaurer une sauvegarde ancienne sans vérifier qu’elle est saine, d’installer plusieurs extensions de sécurité en parallèle et d’ignorer une éventuelle infection de la base de données. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

Les signes d’un piratage sont variés : redirections vers des sites inconnus, avertissement Google du type « ce site peut avoir été piraté », comptes administrateurs non reconnus, fichiers PHP inconnus, envoi d’e-mails de spam, ralentissements anormaux, impossibilité de se connecter ou alerte d’un scanner de sécurité. Cette liste recoupe à la fois les indicateurs pratiques observés par Wordfence et les avertissements de Google Search Console lorsqu’un site est suspecté d’être piraté ou d’héberger du contenu dangereux. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

Le guide ci-dessous suit un ordre d’intervention strict : confirmer les symptômes, isoler le site, sauvegarder les preuves, nettoyer les fichiers et la base de données, réinitialiser tous les accès, corriger la cause d’entrée, vérifier l’état du référencement et seulement ensuite remettre en ligne. Quand le doute est fort sur l’étendue de la compromission, quand le site traite des données sensibles ou quand l’infection touche le serveur au-delà de WordPress, il est généralement plus prudent de faire intervenir un prestataire spécialisé. Wordfence indique d’ailleurs que l’analyse complète dépasse souvent les capacités d’un propriétaire de site sans accès technique ou sans données suffisantes, et propose des services d’incident response précisément pour ce cas. ([wordfence.com](https://www.wordfence.com/help/incident-response-services/?utm_source=openai))

1. Confirmer l’incident et évaluer sa gravité

Avant toute manipulation, il faut déterminer si l’on a affaire à un vrai piratage, à un faux positif, ou à un problème fonctionnel sans compromission. Les signaux les plus sérieux sont la création d’utilisateurs administrateurs inconnus, la modification non expliquée de fichiers du cœur, d’un thème ou d’une extension, l’apparition de nouveaux fichiers PHP, des injections de liens ou de pages spam, des redirections côté visiteur, ou une notification Google Search Console de type sécurité ou site piraté. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

Si Google affiche une alerte dans les résultats de recherche ou dans Chrome, cela signifie que le site a pu être signalé pour contenu dangereux, spam ou compromission. Google précise qu’un propriétaire vérifié dans Search Console peut recevoir un e-mail d’alerte et qu’une demande de réexamen peut ensuite être soumise une fois le problème corrigé. Google précise aussi qu’il peut s’écouler quelques jours avant que les mises à jour soient répercutées entre Safe Browsing, Chrome et Search Console. ([support.google.com](https://support.google.com/webmasters/answer/6347750?hl=en&utm_source=openai))

À ce stade, posez trois questions simples :

Le site est-il encore en train de nuire aux visiteurs ? Redirection, téléchargement dangereux, spam visible, formulaires compromis.
Le compte d’administration ou l’hébergement sont-ils compromis ? Connexion refusée, comptes inconnus, mots de passe changés.
L’attaque semble-t-elle limitée à WordPress ou touche-t-elle le serveur ? Autres sites du même hébergement affectés, tâches cron suspectes, scripts tiers oubliés, fichiers hors installation WordPress.

Plus l’incident dépasse WordPress lui-même, plus l’intervention d’un professionnel devient recommandée. Wordfence cite notamment comme facteurs de risque les scripts tiers non maintenus dans l’hébergement, les sauvegardes publiques accessibles et les vulnérabilités serveur, par exemple une version de PHP en fin de vie. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

2. Passer le site en mode sécurisé avant de nettoyer

La priorité n’est pas de « faire joli », mais d’empêcher l’aggravation. Si le site distribue du code malveillant ou redirige des visiteurs, il faut le sortir du trafic public le plus vite possible. En pratique, cela passe par une page de maintenance statique au niveau serveur, une restriction d’accès temporaire, ou une désactivation applicative décidée avec l’hébergeur. Si l’hébergeur a déjà suspendu le site, il faut le contacter avant toute action destructrice afin de coordonner l’accès et la collecte d’éléments techniques. Wordfence indique explicitement que son équipe peut intervenir même quand l’hébergeur a coupé le site. ([wordfence.com](https://www.wordfence.com/help/incident-response-services/?utm_source=openai))

Cette phase d’isolement doit limiter l’impact sans effacer la scène. Autrement dit, on évite les mises à jour massives immédiates, la suppression en vrac de fichiers inconnus et les réinstallations précipitées tant que les preuves essentielles n’ont pas été copiées. OWASP recommande, avant tout rollback, de capturer les preuves : captures d’écran, journaux, messages d’erreur, contenus de fichiers modifiés, requêtes de base de données et indices d’élévation de privilèges. ([owasp.org](https://owasp.org/APTS/standard/appendix/Incident_Response_Integration.html?utm_source=openai))

Si le site gère des données clients, des comptes membres, des commandes ou des informations personnelles, il faut parallèlement ouvrir un volet de gestion d’incident plus large : analyse de la portée, conservation des traces, coordination avec l’hébergeur et éventuelles obligations de notification selon le contexte juridique et contractuel. Sur ce point, si vous n’avez pas de procédure interne claire, il est préférable d’escalader rapidement. ([owasp.org](https://owasp.org/APTS/standard/appendix/Incident_Response_Integration.html?utm_source=openai))

3. Sauvegarder les preuves et créer une copie de travail

Avant nettoyage, créez une copie complète du site compromis : fichiers, base de données et journaux disponibles. Wordfence insiste sur ce point : il faut d’abord disposer d’une copie du site piraté pour ne pas perdre l’état de l’infection et pour pouvoir revenir en arrière si une étape de nettoyage casse quelque chose. ([wordfence.com](https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence?utm_source=openai))

Concrètement, il faut conserver au minimum :

une archive complète des fichiers du site ;
un export de la base de données ;
les logs d’accès web et d’erreurs si l’hébergeur les fournit ;
la liste des utilisateurs WordPress ;
des captures des pages infectées, redirections, alertes Google, résultats de scan ;
la date et l’heure des constatations.

Ne travaillez pas directement sur l’unique copie du site compromis. Idéalement, on clone l’environnement pour inspecter et nettoyer, puis on réapplique proprement les corrections sur une base saine. OWASP rappelle que l’un des problèmes récurrents en réponse à incident est l’absence de données exploitables au moment où l’on cherche à comprendre ce qui s’est passé ; d’où l’importance des journaux et de leur conservation. ([owasp.org](https://owasp.org/dev-pages/general/logging/index.html?utm_source=openai))

4. Identifier le point d’entrée probable

Nettoyer sans comprendre comment l’attaquant est entré, c’est préparer la réinfection. Il faut donc rechercher les causes plausibles : extension vulnérable non mise à jour, thème abandonné, compte administrateur compromis, mot de passe faible ou réutilisé, script tiers oublié dans l’hébergement, version PHP obsolète, permissions de fichiers trop larges, ou machine locale infectée. Le guide de durcissement de WordPress rappelle qu’aucune sécurité côté application ou serveur ne compensera un poste de travail compromis par un keylogger. ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))

Dans WordPress, commencez par lister précisément :

la version du cœur, des extensions et des thèmes ;
les composants inactifs encore installés ;
les comptes ayant le rôle administrateur ;
les dates de modification des fichiers ;
les éléments présents hors dépôt officiel ou hors processus normal de déploiement.

WordPress recommande de maintenir le cœur, les thèmes et les extensions à jour ; la documentation sur Site Health rappelle qu’un site « healthy » est notamment entièrement à jour et fonctionne avec des versions logicielles adaptées. La documentation sur les mises à jour automatiques souligne aussi qu’il faut toujours maintenir les thèmes et extensions dans leur dernière version, avec des sauvegardes régulières testées en amont. ([wordpress.org](https://wordpress.org/documentation/site-health/?utm_source=openai))

5. Nettoyer les fichiers WordPress méthodiquement

Le nettoyage des fichiers doit suivre une logique de comparaison avec des sources de confiance. Wordfence explique que son scanner compare les fichiers du cœur WordPress, ainsi que ceux des thèmes et extensions disponibles dans le répertoire, avec leurs originaux afin de repérer les modifications. WP-CLI fournit en complément une commande officielle, wp core verify-checksums, qui compare les fichiers du cœur à leurs checksums WordPress.org sans charger WordPress, précisément pour des raisons de sécurité. ([wordfence.com](https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence?utm_source=openai))

La méthode la plus robuste consiste à :

remplacer les fichiers du cœur WordPress par une copie saine de la même version ou d’une version corrigée ;
réinstaller depuis des sources officielles les extensions et thèmes conservés ;
supprimer les extensions, thèmes et médias non reconnus ou inutiles ;
examiner particulièrement les répertoires écrivable, comme wp-content/uploads, souvent utilisés pour cacher des scripts ;
contrôler les fichiers sensibles comme .htaccess, wp-config.php et les chargeurs ajoutés en racine.

Si un fichier du cœur ne correspond pas aux checksums, WP-CLI le signalera. Si des éléments inconnus apparaissent en racine avec l’option d’inclusion des fichiers hors périmètre standard, cela peut constituer un indice utile, mais il faut encore distinguer un ajout légitime d’un dépôt malveillant. ([developer.wordpress.org](https://developer.wordpress.org/cli/commands/core/verify-checksums/?utm_source=openai))

Le point délicat concerne le « code suspect » non clairement classé comme malveillant. Wordfence rappelle qu’un code obfusqué ou utilisant certaines fonctions dangereuses n’est pas automatiquement malveillant, mais qu’en pratique son analyse demande une vraie compréhension du code et de son contexte. Si vous ne savez pas qualifier une séquence PHP, mieux vaut ne pas improviser : isolez le fichier, comparez-le à l’original et escaladez si nécessaire. ([wordfence.com](https://www.wordfence.com/learn/remove-suspicious-code-wordpress/?utm_source=openai))

Évitez aussi une erreur fréquente : croire qu’une extension de sécurité installée après coup « nettoiera tout ». Wordfence indique clairement qu’une extension de sécurité seule ne répare pas automatiquement un site déjà piraté. Elle aide à détecter, comparer et supprimer, mais certaines infections exigent une révision manuelle et parfois une réponse professionnelle. ([wordfence.com](https://www.wordfence.com/how-to-secure-a-wordpress-site/?utm_source=openai))

6. Nettoyer la base de données, pas seulement les fichiers

Beaucoup de nettoyages échouent parce qu’ils s’arrêtent au système de fichiers. Or Wordfence avertit qu’une partie de l’infection peut se trouver dans une table de base de données que son scanner ne parcourt pas, ce qui impose alors un nettoyage manuel. Les contenus injectés peuvent prendre la forme de liens spam, de JavaScript inséré dans des options, d’utilisateurs frauduleux, de modifications de réglages du site, voire de contenu caché dans des articles ou des métadonnées. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

Il faut donc contrôler au minimum :

les utilisateurs et leurs rôles ;
les options du site ;
les contenus publiés récemment sans explication ;
les métadonnées associées aux contenus ;
les tables créées par des extensions désormais supprimées, si elles restent exposées à une persistance malveillante.

Le nettoyage base de données par base de données est l’une des zones où l’aide d’un prestataire devient souvent rentable. Supprimer une option ou une ligne sans comprendre son rôle peut casser un site ; ne rien supprimer peut laisser la charge utile active.

7. Réinitialiser tous les accès après confirmation du nettoyage

L’ordre ici compte énormément : WordPress rappelle qu’il faut changer les mots de passe après s’être assuré que le site est propre. Sinon, l’attaquant encore présent peut simplement récupérer les nouveaux secrets. WordPress recommande un reset global des mots de passe, en particulier pour les administrateurs. ([wordpress.org](https://wordpress.org/documentation/article/faq-my-site-was-hacked/?utm_source=openai))

Une fois le nettoyage suffisamment avancé, réinitialisez :

tous les mots de passe WordPress, surtout administrateurs et éditeurs ;
les accès d’hébergement ;
les accès SFTP ou SSH ;
les identifiants de base de données si possible ;
les clés et sels de sécurité WordPress dans wp-config.php.

WP-CLI propose une commande officielle pour réinitialiser les mots de passe d’utilisateurs, y compris en lot : wp user reset-password. Côté WordPress, les clés secrètes et salts du fichier de configuration doivent être fortes, aléatoires et mises à jour pour maximiser la sécurité ; leur rotation force aussi la révocation de sessions existantes. ([developer.wordpress.org](https://developer.wordpress.org/cli/commands/user/reset-password/?utm_source=openai))

Pensez également à supprimer les comptes inconnus, à vérifier les adresses e-mail des comptes administrateurs, et à activer l’authentification à deux facteurs lorsque votre pile d’outils le permet. Wordfence place l’activation de la 2FA et la revue des utilisateurs parmi les mesures prioritaires après nettoyage. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

8. Corriger la cause racine et durcir l’installation

Remettre en ligne un site simplement « nettoyé » mais pas durci revient à rejouer l’incident. Le guide officiel de durcissement WordPress recommande notamment de verrouiller autant que possible les permissions de fichiers, de protéger wp-config.php, de désactiver l’édition de fichiers depuis l’administration et de surveiller les journaux. Les permissions génériques citées dans la documentation sont souvent 755 pour les répertoires et 644 pour les fichiers, avec des restrictions plus serrées possibles sur certains éléments sensibles comme wp-config.php. ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))

Les mesures minimales après incident sont les suivantes :

mettre à jour immédiatement WordPress, les thèmes et les extensions conservés ;
supprimer les composants inutilisés, abandonnés ou téléchargés hors source officielle ;
désactiver l’édition de fichiers via la configuration WordPress ;
resserrer les permissions sur les fichiers et répertoires ;
vérifier la santé du site avec l’outil Site Health ;
contrôler le fonctionnement des mises à jour, y compris en arrière-plan pour les correctifs de sécurité ;
mettre en place des sauvegardes régulières testées ;
activer une surveillance des changements de fichiers, des scans et des alertes.

Au 17 juillet 2026, WordPress 7.0.2 a été publié comme version de sécurité, avec recommandation explicite de mise à jour immédiate. Ce rappel n’implique pas que tous les sites compromis soient dus à cette version, mais il illustre un point essentiel : dans une phase post-incident, il faut vérifier l’état exact des versions et appliquer les correctifs de sécurité disponibles au moment de l’intervention. ([wordpress.org](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/?utm_source=openai))

9. Vérifier l’indexation, le blacklistage et la réputation du site

Une fois le nettoyage technique achevé, il faut traiter l’impact visible côté recherche et navigateurs. Google Search Console permet d’examiner le rapport sur les problèmes de sécurité, de consulter des échantillons d’URL affectées, puis de demander un réexamen lorsque le site est corrigé. Google indique aussi que l’outil Removals de Search Console permet de masquer temporairement une URL des résultats pendant environ six mois, mais qu’il s’agit d’un retrait temporaire qui ne remplace pas la suppression ou la correction réelle du contenu. ([support.google.com](https://support.google.com/webmasters/answer/9044101?hl=en&utm_source=openai))

En complément, le rapport de transparence Safe Browsing permet de vérifier si une URL est actuellement considérée comme dangereuse. Google précise que sa technologie Safe Browsing examine des milliards d’URL par jour et découvre chaque jour des milliers de nouveaux sites dangereux, dont beaucoup sont des sites légitimes compromis. ([transparencyreport.google.com](https://transparencyreport.google.com/safe-browsing?utm_source=openai))

Ne remettez pas pleinement le site en promotion avant d’avoir vérifié :

l’absence de nouvelles redirections ;
l’absence d’alertes de sécurité dans Search Console ;
le bon comportement de pages clés ;
la disparition des contenus injectés de l’index, si vous en aviez ;
la réception normale des e-mails applicatifs légitimes.

Google précise enfin que la propagation des corrections peut prendre quelques jours entre ses différents systèmes. Il faut donc prévoir un délai entre la réparation et le retour complet à la normale côté avertissements publics. ([support.google.com](https://support.google.com/webmasters/answer/6347750?hl=en&utm_source=openai))

10. Remettre en ligne progressivement

La remise en ligne doit être graduelle. D’abord, on vérifie sur un environnement contrôlé que le cœur, le thème actif, les extensions retenues, les formulaires, les transactions et les tâches planifiées fonctionnent. Ensuite seulement, on rouvre au trafic public. Cette phase doit inclure un dernier scan, un contrôle des permissions et une revue des comptes. Wordfence recommande d’ailleurs, après nettoyage, de concentrer l’effort sur la réduction du « blast radius » : limiter les dégâts possibles en cas de retour de l’attaquant. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

Si le site dépend d’extensions commerciales ou de code sur mesure, il faut redoubler de prudence : la réinstallation depuis une source saine est préférable à la conservation d’anciens paquets dont l’intégrité n’est pas certaine. Pour les extensions du répertoire officiel, les mécanismes de comparaison et de réinstallation sont plus simples ; pour le sur-mesure, la référence doit être votre dépôt privé ou votre archive de déploiement validée.

11. Outils utiles pendant la crise

Quelques outils ressortent clairement des sources consultées :

Wordfence pour le scan, l’identification de fichiers modifiés, l’aide au nettoyage et la revue des résultats. ([wordfence.com](https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence?utm_source=openai))
WP-CLI pour vérifier les checksums du cœur avec wp core verify-checksums et réinitialiser les mots de passe avec wp user reset-password. ([developer.wordpress.org](https://developer.wordpress.org/cli/commands/core/verify-checksums/?utm_source=openai))
Google Search Console pour les rapports de sécurité, les demandes de réexamen et, au besoin, les suppressions temporaires d’URL. ([support.google.com](https://support.google.com/webmasters/answer/9044101?hl=en&utm_source=openai))
Google Safe Browsing Transparency Report pour contrôler l’état public d’une URL. ([transparencyreport.google.com](https://transparencyreport.google.com/safe-browsing?utm_source=openai))
Site Health dans WordPress pour vérifier l’état général du site et certains prérequis de maintenance. ([wordpress.org](https://wordpress.org/documentation/site-health/?utm_source=openai))

Aucun de ces outils ne dispense d’un jugement technique. Ils aident à voir, comparer, confirmer et documenter ; ils ne remplacent pas une investigation complète si la compromission est profonde.

12. Pièges à éviter absolument

Restaurer une sauvegarde au hasard sans vérifier qu’elle date d’avant l’intrusion et qu’elle n’est pas elle-même compromise. Wordfence met explicitement en garde contre ce réflexe. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))
Installer plusieurs extensions de sécurité d’un coup, ce qui complique l’analyse et peut provoquer des conflits. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))
Oublier la base de données alors que l’infection peut s’y maintenir. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))
Changer les mots de passe avant nettoyage puis considérer l’incident clos. WordPress recommande au contraire d’attendre que le site soit propre. ([wordpress.org](https://wordpress.org/documentation/article/faq-my-site-was-hacked/?utm_source=openai))
Télécharger des fichiers WordPress depuis des sites non officiels. Le guide de durcissement WordPress rappelle qu’il ne faut jamais installer WordPress depuis une autre source que WordPress.org. ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))
Négliger le poste local de l’administrateur si une compromission d’identifiants est suspectée. WordPress souligne qu’un keylogger côté machine rend vaines de nombreuses protections côté site. ([developer.wordpress.org](https://developer.wordpress.org/advanced-administration/security/hardening/?utm_source=openai))

13. Quand faire intervenir un prestataire

Il vaut mieux passer la main si l’un des cas suivants se présente :

vous ne savez pas distinguer un fichier légitime d’une porte dérobée ;
plusieurs sites du même hébergement sont touchés ;
des données sensibles ou clients sont potentiellement exposées ;
le site génère encore des redirections ou du spam malgré un premier nettoyage ;
vous n’avez pas accès aux logs ni au shell ;
l’hébergeur a suspendu le compte ;
vous suspectez un accès serveur, SSH, cron ou base de données au-delà de WordPress.

Wordfence présente ses services d’incident response comme une restauration du site compromis, avec suppression des malwares, investigation du point d’entrée, aide au retrait des blocklists et checklist de protection future. Sans adopter un prestataire en particulier, cette description résume bien ce qu’on doit attendre d’une intervention professionnelle sérieuse. ([wordfence.com](https://www.wordfence.com/help/incident-response-services/?utm_source=openai))

14. Mesures post-incident pour éviter la récidive

Un incident n’est réellement clos que si le site ressort plus robuste qu’avant. Le socle minimal est clair dans les sources : mises à jour du cœur, des thèmes et des extensions, suppression des composants inutiles, mots de passe renforcés, 2FA pour les comptes sensibles, sauvegardes régulières et surveillance continue. Wordfence insiste sur l’approche « defense in depth » et sur la réduction du rayon d’impact ; WordPress, de son côté, insiste sur le durcissement, les permissions, la protection de wp-config.php, la désactivation de l’édition de fichiers et la surveillance. ([wordfence.com](https://www.wordfence.com/help/if-your-site-is-hacked/?utm_source=openai))

En pratique, cela veut dire :

tenir un inventaire des extensions et thèmes autorisés ;
supprimer définitivement les composants inactifs qui ne servent plus ;
tester les sauvegardes, pas seulement les générer ;
contrôler régulièrement Site Health ;
surveiller les changements de fichiers ;
réviser les comptes administrateurs et leurs appareils ;
préparer une procédure de réponse à incident documentée, même légère.

La bonne nouvelle, c’est qu’un WordPress piraté peut souvent être nettoyé correctement. La mauvaise, c’est qu’un nettoyage partiel donne une fausse impression de sécurité. En crise, l’objectif n’est pas seulement de remettre le site debout ; c’est de le remettre en ligne propre, vérifié, durci et surveillé. C’est cet ordre-là qui fait la différence entre une reprise solide et une rechute rapide. ([wordfence.com](https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence?utm_source=openai))