Site WordPress piraté : que faire dans la première heure

Si votre site WordPress est piraté, la première heure sert à contenir l’attaque, pas à la réparer : mettez le site hors ligne, copiez les preuves (fichiers, base de données, journaux), puis changez tous les accès. Ensuite seulement, vous cherchez les comptes administrateurs inconnus et les fichiers suspects, vous mettez à jour le cœur et les extensions, et vous renouvelez les clés de sécurité. Si des données personnelles ont pu fuiter, vous avez 72 heures pour évaluer la situation et, le cas échéant, notifier la CNIL.

Voici la checklist dans l’ordre où nous l’appliquons. Elle suppose un accès à l’hébergement (FTP/SFTP ou gestionnaire de fichiers) et, idéalement, à WP-CLI, l’outil en ligne de commande de WordPress.

Comment savoir si votre site WordPress est vraiment piraté ?

Un piratage ne se voit pas toujours sur la page d’accueil. Les signes les plus fréquents :

• des redirections vers des sites de jeux, de pharmacie ou d’arnaque, parfois uniquement sur mobile ou depuis Google ;
• un ou plusieurs comptes administrateurs que personne ne connaît ;
• des pages en langue étrangère indexées sous votre nom de domaine (visible avec la recherche site:votredomaine.fr dans Google) ;
• un avertissement « Site dangereux » dans le navigateur ou dans la Search Console ;
• un e-mail de votre hébergeur signalant un envoi massif de spam ou une suspension ;
• des fichiers PHP apparus dans wp-content/uploads, un dossier qui ne devrait contenir que des médias.

Un seul de ces signes suffit pour déclencher la procédure ci-dessous. Mieux vaut une fausse alerte traitée sérieusement qu’une porte dérobée laissée en place.

Que faire dans les 15 premières minutes ?

1. Isoler le site

L’objectif est d’empêcher l’attaquant d’agir et de protéger vos visiteurs. Selon vos accès :

• activez le mode maintenance de votre hébergeur, ou créez un fichier .maintenance à la racine du site ;
• ou restreignez l’accès par IP dans le fichier .htaccess (Apache) ou la configuration Nginx, pour ne laisser passer que votre adresse ;
• coupez les tâches automatiques sensibles : envois de newsletter, synchronisations, paiements récurrents.

Ne supprimez rien à ce stade. Effacer des fichiers suspects avant de les avoir copiés, c’est perdre la trace de la porte d’entrée.

2. Sauvegarder les preuves

Faites une copie complète de l’état infecté, stockée hors du serveur :

1. l’ensemble des fichiers du site (archive ZIP ou tar) ;
2. un export de la base de données, par exemple avec wp db export preuve-infection.sql ou phpMyAdmin ;
3. les journaux d’accès et d’erreurs du serveur (souvent disponibles dans l’espace client de l’hébergeur, conservés peu de temps) ;
4. des captures d’écran des symptômes, avec la date et l’heure.

Ces éléments servent à comprendre comment l’attaquant est entré, à prouver la date de l’incident si vous devez notifier la CNIL, et à répondre à votre assureur le cas échéant.

Quels accès changer, et dans quel ordre ?

Partez du principe que tous les mots de passe liés au site sont connus de l’attaquant. Changez-les depuis un ordinateur sain, en commençant par les plus puissants :

1. le compte de l’hébergeur (et activez la double authentification) ;
2. les accès FTP/SFTP et SSH ;
3. le mot de passe de la base de données, puis la constante DB_PASSWORD dans wp-config.php ;
4. tous les comptes administrateurs et éditeurs WordPress ;
5. les « mots de passe d’application » (menu Profil), à révoquer s’ils ne sont pas utilisés ;
6. les clés API stockées dans les extensions : paiement, e-mailing, CRM, SMTP.

Comment trouver les administrateurs inconnus et les fichiers suspects ?

Les comptes

Dans Comptes > Tous les comptes, filtrez par rôle « Administrateur ». En ligne de commande : wp user list --role=administrator --fields=ID,user_login,user_email,user_registered. Regardez la date d’inscription : un compte créé la nuit, avec une adresse e-mail jetable, est un signal fort. Vérifiez aussi la table wp_usermeta : un attaquant peut attribuer la capacité administrateur via la clé wp_capabilities à un compte qui apparaît comme simple abonné.

Les fichiers

• wp core verify-checksums compare les fichiers du cœur avec les originaux publiés par WordPress.org ;
• wp plugin verify-checksums --all fait de même pour les extensions du répertoire officiel ;
• find wp-content/uploads -name "*.php" liste les fichiers PHP cachés parmi les médias ;
• find . -name "*.php" -mtime -10 liste les fichiers PHP modifiés ces 10 derniers jours ;
• cherchez les fonctions souvent utilisées par les portes dérobées : grep -rl "eval(base64_decode" wp-content ;
• inspectez le dossier wp-content/mu-plugins, que beaucoup oublient et qui s’exécute automatiquement.

Côté base de données, contrôlez la table wp_options (valeurs siteurl et home, options inconnues contenant du JavaScript) et les tâches planifiées avec wp cron event list.

Mettre à jour et renouveler les clés de sécurité

Une fois les portes dérobées retirées, fermez la faille par laquelle l’attaquant est entré :

• réinstallez le cœur proprement : wp core download --force --skip-content, puis wp core update ;
• mettez à jour toutes les extensions et thèmes (wp plugin update --all, wp theme update --all) ;
• supprimez les extensions et thèmes désactivés ou abandonnés par leur auteur ;
• renouvelez les clés et sels de wp-config.php avec wp config shuffle-salts (ou via le générateur officiel de WordPress.org). Cette opération déconnecte toutes les sessions ouvertes, y compris celles de l’attaquant.

Le cas de la faille « wp2shell »

La faille baptisée « wp2shell » (CVE-2026-63030 et CVE-2026-60137) touche le cœur de WordPress. Elle combine l’API REST batch (/wp-json/batch/v1) et une injection SQL. Elle a été divulguée et corrigée le 17 juillet 2026, dans WordPress 6.9.5 et 7.0.2. Elle a ensuite été exploitée massivement pour créer des comptes administrateurs pirates. Si votre site tournait sur une version antérieure à ces correctifs, la recherche d’administrateurs inconnus décrite plus haut est prioritaire, et la mise à jour du cœur n’est pas négociable.

Faut-il prévenir la CNIL ou vos clients ?

Oui si des données personnelles ont pu être consultées, copiées ou modifiées : comptes clients, commandes WooCommerce, formulaires de contact enregistrés, inscrits à une newsletter. Le RGPD impose de notifier la CNIL dans les 72 heures après avoir pris connaissance de la violation, sauf si elle ne présente pas de risque pour les personnes. Si le risque est élevé (mots de passe, données bancaires, données de santé), vous devez aussi informer les personnes concernées. Dans tous les cas, documentez l’incident dans votre registre interne des violations.

Situation	Notification CNIL	Information des personnes
Défiguration sans accès aux données	Non, mais consigner l’incident	Non
Accès possible à des e-mails ou coordonnées	Oui, sous 72 h si risque pour les personnes	Selon le niveau de risque
Fuite de mots de passe, données de santé ou bancaires	Oui, sous 72 h	Oui, dans les meilleurs délais

La notification se fait en ligne sur le site de la CNIL. Vous pouvez la compléter plus tard si l’enquête technique n’est pas terminée.

Et après la première heure ?

Une fois le site propre et remis en ligne, demandez un nouvel examen dans la Search Console si Google l’a signalé comme dangereux, surveillez les journaux quelques jours, et mettez en place une routine pour éviter la récidive. Notre checklist de maintenance WordPress mensuelle détaille les contrôles qui auraient permis de repérer l’intrusion plus tôt. Si le site doit changer d’hébergeur à cette occasion, suivez notre méthode pour migrer un site WordPress sans rien casser, en migrant uniquement une version nettoyée. Enfin, si des formulaires ou des outils automatisés manipulent des données clients, relisez les règles RGPD applicables à l’automatisation.

Questions fréquentes

Puis-je simplement restaurer une sauvegarde ?

Oui, à condition qu’elle date d’avant l’intrusion, ce qui est souvent difficile à établir. Même après restauration, la faille reste ouverte : il faut mettre à jour le cœur et les extensions, changer les accès et renouveler les clés, sinon le site sera réinfecté.

Une extension de sécurité suffit-elle à nettoyer le site ?

Elle aide à détecter les fichiers modifiés et les codes malveillants connus. Elle ne remplace pas la vérification des comptes, des tâches planifiées et de la base de données, où certaines portes dérobées se cachent.

Combien de temps prend un nettoyage complet ?

Cela dépend de l’ancienneté de l’infection et du nombre d’extensions. Un site vitrine simple se traite généralement en quelques heures, un site e-commerce avec de nombreux comptes demande davantage d’analyse.

Mon hébergeur peut-il s’en occuper ?

Certains hébergeurs proposent une analyse antivirus ou une restauration. Le nettoyage applicatif de WordPress (comptes, extensions, base de données) reste en général à votre charge ou à celle de votre prestataire.

Sources

• Notifier une violation de données personnelles — CNIL
• Défiguration de site Internet, que faire ? — Cybermalveillance.gouv.fr
• wp core verify-checksums – WP-CLI Command — WordPress.org
• WordPress Version 6.9.5 (correctifs de sécurité du 17 juillet 2026) — WordPress.org
• CVE-2026-63030 Detail — National Vulnerability Database (NIST)