Mon site WordPress a été piraté : le guide de nettoyage 2026.

01 · Les signes d'un WordPress réellement piraté

Avant de tout casser, confirmez qu'il s'agit bien d'une compromission et pas d'un simple bug. Les symptômes les plus fiables :

• Redirections inattendues : votre site renvoie vers des pharmacies, des sites de paris ou du contenu pour adultes — souvent uniquement depuis Google ou sur mobile, pour échapper à votre œil.
• Spam SEO injecté : des centaines de pages ou de liens invisibles (viagra, sacs de luxe…) apparaissent dans Google Search Console.
• Alerte officielle : un mail de votre hébergeur, de l'OFCS/NCSC, du CERT-FR, ou l'écran rouge « Site trompeur » de Google Safe Browsing.
• Comptes admin inconnus, fichiers récemment modifiés que vous n'avez pas touchés, pics de trafic ou d'envoi d'e-mails sortants (votre serveur envoie du spam).
• Avertissement antivirus côté visiteur, ou hébergeur qui suspend le compte pour « activité malveillante ».

Un seul de ces signaux suffit à justifier la suite. Plusieurs ensemble : agissez aujourd'hui.

02 · Avant tout : ne supprimez rien, préservez les preuves

Le réflexe « je supprime les fichiers bizarres et je réinstalle » est le plus coûteux. Il efface les traces qui permettent d'identifier comment l'attaquant est entré — donc il reviendra par le même chemin. Avant de toucher quoi que ce soit :

• Faites une copie complète (fichiers + base de données) du site compromis, telle quelle. C'est votre instantané forensique.
• Mettez de côté les logs serveur (accès HTTP, erreurs, SSH/FTP) des 30 derniers jours. Beaucoup d'hébergeurs ne les gardent que quelques jours : récupérez-les immédiatement.
• Notez l'heure de découverte et les premiers symptômes constatés. Si des données personnelles sont concernées, cette chronologie comptera (voir §09).

03 · Isoler le site et couper l'accès de l'attaquant

Objectif : arrêter les dégâts en cours sans détruire les preuves.

• Passez le site en maintenance (page statique) plutôt que de le laisser servir du malware à vos visiteurs et polluer votre réputation.
• Changez tous les mots de passe : comptes admin WordPress, base de données, FTP/SFTP, SSH, panneau d'hébergement, et les comptes e-mail associés. Faites-le depuis un poste sain.
• Invalidez les sessions et révoquez les clés d'API / jetons applicatifs qui traînent.
• Coupez les accès superflus : si seuls 2 admins sont légitimes, désactivez le reste le temps de l'intervention.

04 · Diagnostic : scanner et localiser l'infection

Combinez plusieurs approches — aucun scanner seul n'attrape tout.

Scanners WordPress

Des outils comme Wordfence, Sucuri SiteCheck, MalCare ou WPScan détectent les signatures connues, les plugins vulnérables et les fichiers modifiés. Utiles pour un premier balayage, mais ils ratent les backdoors sur mesure.

Vérifier l'intégrité du core

WP-CLI compare vos fichiers WordPress aux fichiers officiels et liste tout ce qui a été altéré :

wp core verify-checksums
wp plugin verify-checksums --all

Chasser les fichiers suspects à la main

Les webshells se cachent souvent dans /wp-content/uploads/ (qui ne devrait contenir aucun .php) et se trahissent par des fonctions d'obfuscation :

# Fichiers PHP modifiés ces 7 derniers jours
find . -name "*.php" -mtime -7 -print

# Du PHP là où il ne devrait jamais y en avoir
find ./wp-content/uploads -name "*.php"

# Signatures d'obfuscation courantes
grep -rEl "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|\\\$_POST\[" wp-content/

Un résultat ne prouve pas à lui seul une infection (certains plugins légitimes utilisent ces fonctions), mais c'est une liste de pistes à inspecter une par une.

05 · Identifier le point d'entrée

C'est l'étape que les nettoyages rapides sautent — et c'est elle qui empêche la récidive. Dans 90 % des cas, l'entrée est l'une de celles-ci :

• Plugin ou thème obsolète avec une CVE connue (les page builders et plugins de formulaire sont des cibles récurrentes).
• Identifiants volés (réutilisés, faibles, ou hameçonnés) sur un compte admin, FTP ou hébergeur.
• Thème/plugin nulled (version piratée téléchargée gratuitement) livré avec une backdoor d'origine.
• Voisin compromis sur un hébergement mutualisé mal cloisonné.

Croisez les logs d'accès avec l'horodatage des fichiers modifiés : la première requête anormale vers le fichier malveillant pointe presque toujours vers la faille initiale.

06 · Le nettoyage, fichier par fichier

Dans l'ordre, sur votre copie de travail :

1. Core : remplacez l'intégralité des fichiers WordPress par une installation officielle propre de la même version, en conservant uniquement votre wp-config.php (après l'avoir relu ligne par ligne) et /wp-content/.
2. Plugins & thèmes : réinstallez-les depuis leur source officielle. Supprimez tout ce qui est inutilisé, nulled, ou que vous ne reconnaissez pas. Désinstallez le thème inactif.
3. Uploads : supprimez tout fichier exécutable (.php, .phtml, .suspected) du dossier d'upload.
4. Base de données : cherchez le JavaScript/iframe injecté dans wp_posts et wp_options (notamment les options siteurl/home détournées), et les utilisateurs administrateurs illégitimes dans wp_users/wp_usermeta.
5. Fichiers sensibles : inspectez .htaccess (règles de redirection cachées), les tâches cron (système et wp_cron), et wp-config.php (code injecté en tête/pied).

07 · Durcissement post-incident (l'étape qu'on saute toujours)

Nettoyer sans durcir, c'est laisser la porte ouverte. Le minimum après tout incident :

• Tout à jour : core, plugins, thèmes, PHP. Activez les mises à jour automatiques au moins pour les correctifs de sécurité.
• Authentification forte : mots de passe uniques + 2FA sur tous les comptes admin. Renommez ou protégez la page de connexion, limitez les tentatives.
• Moindre privilège : un compte = un rôle juste suffisant. Pas d'admin « par confort ».
• Verrouiller le code : DISALLOW_FILE_EDIT à true, bloquer l'exécution PHP dans /uploads/, désactiver XML-RPC si inutilisé.
• WAF devant le site (au niveau edge ou serveur) pour filtrer les attaques connues et les bots.
• Sauvegardes régulières, testées, et stockées hors du serveur (une sauvegarde sur le serveur compromis ne vaut rien).

08 · Remise en ligne et levée des blacklists

Une fois le site propre et durci :

• Remettez en ligne progressivement et surveillez les logs les premiers jours.
• Dans Google Search Console → Problèmes de sécurité, demandez un réexamen pour lever l'avertissement Safe Browsing. Faites de même chez les autres listes si vous y êtes (Yandex, fournisseurs antivirus).
• Demandez à votre hébergeur la réactivation si le compte avait été suspendu, en joignant le résumé de l'intervention.
• Surveillez la réapparition de symptômes pendant 2 à 4 semaines : une récidive rapide signifie qu'un point d'entrée a été manqué (retour au §05).

09 · Vos obligations légales (nLPD / RGPD)

Si la compromission a pu exposer des données personnelles (comptes clients, commandes, e-mails), vous avez probablement une obligation de notification :

• RGPD (UE) : notification à l'autorité (CNIL en France, APD en Belgique…) dans les 72 heures après en avoir pris connaissance, si la violation présente un risque pour les personnes.
• nLPD (Suisse) : annonce au PFPDT « dans les meilleurs délais » en cas de risque élevé — pas de délai fixe, mais rapide.

D'où l'intérêt de la préservation des preuves du §02 : évaluer factuellement ce qui a été touché conditionne le contenu de la notification. Ce guide ne remplace pas un conseil juridique.

10 · Le faire soi-même, ou appeler une équipe ?

Soyons honnêtes sur les limites du DIY. Vous pouvez gérer vous-même si : le site est simple, sans données sensibles, vous avez une sauvegarde saine datée, et vous êtes à l'aise avec SSH et la base de données.

Faites appel à une équipe de réponse à incident si : c'est un e-commerce ou un site critique, des données clients sont concernées, l'attaquant revient malgré vos nettoyages, plusieurs sites sont touchés, ou vous avez reçu une alerte officielle (OFCS, CERT-FR, hébergeur). Un audit forensique trace le point d'entrée précis, ce qu'un nettoyage à l'aveugle ne fait pas.