Face à un site WordPress piraté, l'ordre des actions compte plus que la vitesse. Isoler, sauvegarder l'état, changer les accès, identifier, restaurer, et notifier la CNIL si des données personnelles sont touchées.
Si votre site WordPress est piraté, ne commencez pas par tout effacer. Dans la première heure : isolez le site (maintenance ou coupure), copiez son état actuel pour garder les preuves, changez tous les accès (administration, FTP/SFTP, hébergement, base de données), puis repérez les comptes administrateurs et les fichiers ajoutés ou modifiés. Ensuite seulement, restaurez une sauvegarde saine, mettez tout à jour et, si des données personnelles ont été exposées, préparez la notification à la CNIL, à faire dans les 72 heures lorsque la violation présente un risque pour les personnes.
Un piratage provoque un réflexe compréhensible : tout remettre en ordre au plus vite. C’est pourtant dans cette précipitation que l’on efface les traces utiles, que l’on restaure une sauvegarde déjà infectée ou que l’on oublie une porte dérobée. Voici l’ordre des opérations que nous suivons, heure par heure.
- Comment savoir si votre site est vraiment piraté ?
- Minutes 0 à 10 : isoler le site
- Minutes 10 à 20 : sauvegarder l’état du site piraté
- Minutes 20 à 35 : changer tous les accès
- Minutes 35 à 60 : identifier comptes et fichiers suspects
- Après la première heure : restaurer et mettre à jour
- Données personnelles : faut-il prévenir la CNIL ?
- Ce que nous avons appris en 2026
- Les erreurs à éviter
- Questions fréquentes
- Sources
Comment savoir si votre site est vraiment piraté ?
« Piraté » recouvre des situations très différentes. La documentation officielle de WordPress invite d’abord à lister les symptômes précis, appelés indicateurs de compromission. Les plus clairs :
- des comptes utilisateurs que personne n’a créés, en particulier des administrateurs ;
- des redirections vers des sites de jeux, de pharmacie ou d’arnaque, parfois uniquement sur mobile ou depuis Google ;
- un avertissement de Google ou de l’antivirus des visiteurs signalant un site dangereux ;
- des pages inconnues qui apparaissent dans les résultats de recherche ;
- votre hébergeur qui suspend le site ou vous signale un envoi massif d’e-mails ;
- un contenu visiblement modifié (défiguration).
Un site lent ou en erreur n’est pas forcément piraté : une erreur 503 ou une erreur critique vient bien plus souvent d’une mise à jour ou d’une extension. Mais si vous observez l’un des signes ci-dessus, traitez la situation comme un incident de sécurité. Notez tout de suite ce que vous voyez, avec l’heure : ce sera le début de votre rapport d’incident.
Minutes 0 à 10 : isoler le site
L’objectif est d’empêcher l’attaquant de continuer et de protéger vos visiteurs. Selon vos accès :
- Prévenez votre hébergeur. Il peut suspendre le site, bloquer des adresses IP, et vérifier si d’autres sites du même compte sont touchés (fréquent en hébergement mutualisé).
- Coupez l’accès public : page de maintenance au niveau du serveur, restriction par adresse IP, ou suspension par l’hébergeur. Évitez de passer par une extension WordPress : si WordPress est compromis, vous ne pouvez pas lui faire confiance.
- Ne supprimez rien encore. Ni fichier suspect, ni compte inconnu. Vous en aurez besoin pour comprendre l’étendue du problème.
Le dispositif national Cybermalveillance.gouv.fr recommande, dans sa fiche réflexe sur la défiguration de site, de conserver les machines touchées et les journaux pour les enquêteurs. Isoler plutôt qu’effacer, c’est la même logique.
Minutes 10 à 20 : sauvegarder l’état du site piraté
Cela paraît contre-intuitif, mais c’est une recommandation explicite de la documentation WordPress : avant de nettoyer, faites une copie complète du site dans son état infecté. Elle servira à comprendre ce qui s’est passé, à prouver les faits (dépôt de plainte, assurance, notification CNIL) et à récupérer des données légitimes si la restauration en perd.
- une archive de tous les fichiers du site ;
- un export complet de la base de données ;
- les journaux du serveur web (accès et erreurs) et, si possible, ceux de l’hébergement, qui sont souvent effacés après quelques jours ;
- des captures d’écran datées de ce que vous observez.
Stockez cette copie hors du serveur et identifiez-la clairement comme infectée, pour ne jamais la restaurer par erreur.
Minutes 20 à 35 : changer tous les accès
La documentation WordPress insiste sur un point : il faut changer tous les points d’accès, pour tous les utilisateurs qui y ont accès, pas seulement votre mot de passe WordPress.
| Accès | Action |
|---|---|
| Espace client de l’hébergeur | Nouveau mot de passe, activation de la double authentification |
| FTP, SFTP, SSH | Nouveaux mots de passe, suppression des comptes et clés inconnus |
| Panneau d’administration (cPanel, Plesk…) | Nouveau mot de passe |
| Base de données | Nouveau mot de passe de l’utilisateur MySQL, reporté dans wp-config.php |
| Comptes WordPress | Réinitialisation des mots de passe de tous les administrateurs et éditeurs |
| Sessions WordPress | Renouvellement des clés secrètes (« salts ») de wp-config.php |
| Services connectés | Clés d’API (paiement, e-mail, CRM) stockées dans le site |
Le renouvellement des clés secrètes est souvent oublié. Il déconnecte toutes les sessions ouvertes, y compris celle de l’attaquant. Vous pouvez générer de nouvelles clés sur le générateur officiel de WordPress.org et les coller dans wp-config.php, ou utiliser WP-CLI :
wp config shuffle-salts
Faites aussi analyser votre propre ordinateur. WordPress.org le rappelle : une partie des intrusions commence par un poste infecté qui laisse fuiter les identifiants FTP ou d’administration. Changer les mots de passe depuis un poste compromis ne sert à rien.
Minutes 35 à 60 : identifier comptes et fichiers suspects
Les comptes administrateurs
Listez les administrateurs avec leur date de création. Un compte créé récemment, avec une adresse e-mail inconnue, est un signal fort :
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Sans WP-CLI, la même information se lit dans la table des utilisateurs via phpMyAdmin. Notez ces comptes (identifiant, e-mail, date) avant de les supprimer : la date de création donne souvent l’heure de l’intrusion, donc la date limite des sauvegardes saines.
Les fichiers modifiés ou ajoutés
WP-CLI compare les fichiers du cœur et des extensions officielles avec les empreintes publiées par WordPress.org :
# Fichiers du cœur modifiés, et fichiers en trop à la racine
wp core verify-checksums --include-root
# Extensions issues du répertoire officiel
wp plugin verify-checksums --all
Deux limites : sur un site en français, précisez la langue (--locale=fr_FR) pour éviter de faux positifs, et la vérification des extensions ne fonctionne que pour celles du répertoire WordPress.org. Les extensions premium, le thème et le dossier uploads sont à examiner autrement : fichiers PHP dans wp-content/uploads (qui ne devrait contenir que des médias), fichiers récemment modifiés, fichier .htaccess altéré. WordPress.org cite aussi index.php, header.php, footer.php et functions.php parmi les fichiers les plus souvent visés.
Un scanner de sécurité (extension ou service externe) complète utilement cette analyse, sans la remplacer.
Les données exposées
Posez la question tout de suite : quelles données personnelles le site stocke-t-il ? Messages des formulaires de contact, comptes clients, commandes, inscriptions à la newsletter. La réponse conditionne vos obligations vis-à-vis de la CNIL.
Après la première heure : restaurer et mettre à jour
- Choisissez une sauvegarde antérieure à l’intrusion, en vous appuyant sur la date de création des comptes suspects et des fichiers modifiés. Une sauvegarde d’après l’intrusion contient la porte dérobée.
- Restaurez fichiers et base de données sur un site encore fermé au public. Sans sauvegarde saine, remplacez au minimum
wp-adminetwp-includespar des copies officielles de la même version, puis réinstallez extensions et thème depuis leur source. - Récupérez les données légitimes postérieures à la sauvegarde (commandes, contenus) depuis la copie infectée, avec prudence.
- Mettez tout à jour : WordPress, extensions, thème, version de PHP. Supprimez les extensions inutilisées.
- Changez à nouveau les mots de passe. WordPress.org le recommande explicitement : ceux changés pendant l’incident ont pu être interceptés tant que le site était compromis.
- Réouvrez le site et surveillez : nouveaux comptes, fichiers modifiés, trafic inhabituel, pendant plusieurs semaines.
- Si Google a signalé le site, demandez un examen depuis le rapport « Problèmes de sécurité » de la Search Console une fois tout le site nettoyé. Google indique que cet examen peut prendre de plusieurs jours à plusieurs semaines.
Pour durcir le site ensuite, nos conseils pour sécuriser un site web donnent les bases : double authentification, limitation des tentatives de connexion, droits minimaux, sauvegardes externalisées.
Données personnelles : faut-il prévenir la CNIL ?
Si l’attaque a pu donner accès à des données personnelles (nom, e-mail, téléphone, contenu d’un formulaire), il s’agit d’une violation de données au sens du RGPD. L’article 33 impose au responsable du traitement, c’est-à-dire à votre entreprise, de la notifier à la CNIL « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance », sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes.
Ce qu’il faut retenir sur la CNIL
- Le délai de 72 heures court à partir du moment où vous avez connaissance de la violation.
- Si vous n’avez pas toutes les informations, la CNIL indique qu’une notification initiale est possible, à compléter ensuite. Au-delà de 72 heures, il faut justifier le retard.
- La notification se fait en ligne sur le téléservice de la CNIL.
- Les personnes concernées doivent être informées directement lorsque la violation présente un risque élevé pour elles (article 34).
- Toute violation, même non notifiée, doit être documentée en interne : nature, données et nombre approximatif de personnes touchées, conséquences, mesures prises.
Si vous hésitez sur la nécessité de prévenir les personnes concernées, la CNIL invite à le préciser dans la notification : elle vous indiquera la marche à suivre. Si votre site est géré par un prestataire, c’est à lui de vous alerter, mais c’est à vous, responsable du traitement, de notifier. Enfin, Cybermalveillance.gouv.fr recommande de déposer plainte auprès de la police, de la gendarmerie ou du procureur, en apportant les éléments conservés.
Ce que nous avons appris en 2026
En 2026, nous avons traité plusieurs piratages de sites WordPress clients. Le scénario avait des points communs : les attaquants créaient des comptes administrateurs et récupéraient les données des formulaires. Dans chaque cas, ce sont les sauvegardes horaires qui ont permis de restaurer rapidement un site sain.
Deux enseignements en découlent. D’abord, la liste des administrateurs est l’un des premiers endroits à vérifier : un compte inconnu signale l’intrusion et en date le début. Ensuite, la fréquence des sauvegardes fait la différence : avec une sauvegarde par heure, on perd au pire une heure de contenus ; avec une sauvegarde hebdomadaire, on doit choisir entre perdre une semaine et garder un site douteux. C’est l’un des points que nous détaillons dans notre article sur la maintenance des sites WordPress.
Les erreurs à éviter
- Supprimer le compte suspect et considérer que c’est réglé. Un attaquant qui a créé un compte a souvent aussi déposé un fichier pour revenir.
- Restaurer la dernière sauvegarde disponible sans vérifier qu’elle date d’avant l’intrusion.
- Utiliser le bouton « Réinstaller » de WordPress pour nettoyer. WordPress.org rappelle qu’il écrase les fichiers existants mais ne supprime pas les fichiers ajoutés par l’attaquant.
- Oublier les accès hors WordPress : hébergement, FTP, base de données, clés d’API.
- Laisser passer le délai de 72 heures parce que « ce n’était qu’un formulaire de contact ». Des noms et des e-mails sont des données personnelles.
- Ne pas chercher la cause. Sans correction de la faille (extension obsolète, mot de passe faible, accès partagé), le site sera repiraté.
Si votre site est piraté en ce moment et que vous ne savez pas par où commencer, notre agence WordPress peut prendre le relais sur le nettoyage et la restauration. Et pour ne plus revivre cette situation, notre offre d’hébergement et maintenance inclut mises à jour, sauvegardes et surveillance.
Questions fréquentes
Mon hébergeur est-il responsable du piratage ?
Rarement. L’hébergeur sécurise le serveur ; le site (WordPress, extensions, mots de passe) reste de la responsabilité de son propriétaire ou de son prestataire, sauf offre gérée qui le prévoit par contrat.
Je n’ai pas de sauvegarde, tout est-il perdu ?
Non, mais le nettoyage est plus long : remplacement du cœur et des extensions par des copies officielles, examen manuel du thème, de la base et du dossier uploads. Demandez aussi à votre hébergeur s’il conserve des sauvegardes.
Faut-il prévenir la CNIL si seuls des messages de contact ont fuité ?
Ces messages contiennent au minimum un nom et une adresse e-mail. S’ils ont pu être consultés par l’attaquant, il faut documenter la violation et, sauf absence de risque démontrable, la notifier. En cas de doute, notifiez.
Le piratage va-t-il ruiner mon référencement ?
Un site signalé comme dangereux perd une grande partie de son trafic tant que l’avertissement est affiché. Une fois le site nettoyé, la demande de réexamen dans la Search Console permet de lever l’avertissement.
Faut-il porter plainte ?
Cybermalveillance.gouv.fr le recommande, auprès de la police, de la gendarmerie ou du procureur. Les preuves conservées pendant la première heure servent ici.
Sources
- WordPress.org : FAQ My site was hacked
- WordPress Advanced Administration Handbook : Hardening WordPress
- WP-CLI : wp core verify-checksums
- WP-CLI : wp plugin verify-checksums
- WP-CLI : wp user list
- WP-CLI : wp config shuffle-salts
- Générateur officiel de clés secrètes WordPress
- CNIL : notifier une violation de données personnelles
- RGPD, articles 33 et 34 (texte sur cnil.fr)
- Google Search Console : rapport sur les problèmes de sécurité
- Cybermalveillance.gouv.fr : défiguration de site internet, que faire ?




