Site WordPress piraté : que faire dans la première heure
23 octobre 2026 · 14 min de lecture

Un site qui redirige vers une pharmacie en ligne. Des pages de spam publiées cette nuit. Un administrateur inconnu. Quand un site WordPress piraté révèle les dégâts, la première heure est décisive.
La bonne nouvelle : un piratage WordPress se nettoie, même sans être développeur, à condition de suivre les étapes dans le bon ordre.
En bref
- Confirmez le piratage avant de toucher quoi que ce soit (Search Console, scan externe).
- Changez TOUS les accès depuis une machine saine, hébergeur inclus.
- Réinstallez le cœur de WordPress depuis le tableau de bord, ou à partir de l’archive officielle si vous n’y avez plus accès.
- Ne remettez pas le site en ligne avant un deuxième scan propre.
- Un nettoyage incomplet récidive : la backdoor cherchée en dernier est celle qui revient en premier.
Ce que vous aurez fait à la fin de cette heure
À l’issue de cette procédure, vous aurez :
- Coupé l’accès à l’attaquant sur tous les vecteurs (WordPress, FTP, base de données)
- Restauré les fichiers cœur dans leur version officielle
- Nettoyé les contenus injectés et identifié le vecteur d’entrée
- Préparé la demande de révision auprès de Google, à envoyer une fois le nettoyage confirmé par un second scan propre
Temps estimé : la durée dépend fortement de la gravité de l’intrusion. Un piratage limité à un fichier se règle rapidement. Une compromission totale prend plus de temps, et c’est normal.
Ce qu’il vous faut avant de commencer
Rassemblez ces accès depuis une machine qui n’est pas celle que vous utilisez habituellement, idéalement depuis un autre réseau.
Accès hébergeur, FTP et base de données
- Identifiants de votre panneau d’hébergement (cPanel, Plesk, ISPConfig ou équivalent)
- Accès FTP/SFTP avec le client de votre choix (FileZilla fonctionne bien)
- Accès phpMyAdmin ou équivalent pour la base de données
- Accès au gestionnaire DNS de votre registraire (OVH, Gandi, Namecheap…)
Une sauvegarde récente et ses identifiants
Localisez votre dernière sauvegarde avant de commencer à nettoyer quoi que ce soit. Si vous n’en avez pas, demandez à votre hébergeur s’il en conserve une : la durée de conservation varie selon les offres.
Une sauvegarde inexistante ne bloque pas la procédure, mais elle vous retire votre filet de sécurité. Dans ce cas, exportez immédiatement la base de données depuis phpMyAdmin avant de toucher aux fichiers, même compromise. C’est toujours mieux que rien.
Êtes-vous vraiment piraté ? Les signaux qui ne trompent pas
Avant d’agir, confirmez. Un site WordPress qui affiche une erreur 500 n’est pas nécessairement infecté. Un cache corrompu ou une extension mal mise à jour produit les mêmes symptômes visuels.
Redirections, pages de spam inconnues et comptes administrateurs fantômes
Les signaux sans équivoque :
- Le site redirige vers un domaine étranger depuis un mobile (pas depuis un ordinateur de bureau, les pirates ciblent souvent les navigateurs mobiles)
- Des articles ou pages existent dans WordPress que personne n’a créés : pharmacie, contrefaçon, textes en langue étrangère
- La liste Utilisateurs > Tous les utilisateurs affiche un ou plusieurs comptes administrateurs inconnus
- Le fichier .htaccess contient des règles de redirection que vous n’avez jamais écrites
- Des dossiers inconnus apparaissent à la racine du site via FTP
Un pirate qui injecte du contenu malveillant cible en priorité les pages que Google indexe, pas celles que vous voyez. La consultation de votre site depuis un navigateur classique peut donc ne rien montrer.
Vérifier avec la Search Console et un scan externe
Deux vérifications rapides confirment ou écartent l’intrusion :
- Google Search Console, onglet Sécurité et actions manuelles. Un avertissement « Ce site contient des logiciels malveillants » est sans équivoque. Utilisez aussi la commande site:votredomaine.com dans Google pour voir les pages indexées : si des centaines d’URLs inconnues apparaissent, le piratage est confirmé.
- Sucuri SiteCheck (sitecheck.sucuri.net), scan externe gratuit qui détecte les redirections malveillantes, le contenu blacklisté et les modifications du .htaccess.

Si les deux confirment une intrusion, passez à l’étape suivante sans attendre. Chaque heure supplémentaire laisse l’attaquant actif.
Les 8 gestes à faire dans l’ordre dans la première heure
Beaucoup commencent par changer le mot de passe WordPress. C’est insuffisant. Pendant ce temps, le pirate continue d’opérer via FTP ou la base de données.
1. Couper l’accès public au site sans perdre les traces
Activez le mode maintenance depuis votre hébergeur ou en créant un fichier .maintenance à la racine via FTP. Objectif : empêcher les visiteurs de charger du contenu malveillant et éviter que Google étende sa pénalité. Ne supprimez rien pour l’instant ; les logs et fichiers suspects sont des preuves.
2. Changer tous les mots de passe et révoquer les sessions actives
Depuis votre panneau d’hébergement (pas depuis WordPress) :
- Nouveau mot de passe FTP/SFTP
- Nouveau mot de passe de base de données, puis mettez à jour wp-config.php avec la nouvelle valeur
- Nouveau mot de passe du compte d’hébergement lui-même
- Clés secrètes WordPress : générez-en de nouvelles via api.wordpress.org/secret-key/1.1/salt/ et collez-les dans wp-config.php. Cela déconnecte toutes les sessions actives instantanément.
Le changement de mot de passe sur une machine potentiellement compromise transmet le nouveau mot de passe à l’attaquant. Utilisez une autre machine, sur un autre réseau.
3. Supprimer ou désactiver les comptes administrateurs non reconnus
Dans Utilisateurs > Tous les utilisateurs, supprimez tout compte que vous ne reconnaissez pas. Avant de supprimer, notez l’adresse email associée : elle peut indiquer le vecteur d’entrée (un compte créé via un formulaire de contact, une API tierce, etc.).
Changez également le mot de passe de TOUS les comptes administrateurs existants, pas seulement du vôtre.
4. Réinstaller le cœur de WordPress depuis le tableau de bord
Depuis Tableau de bord > Mises à jour, cliquez sur « Réinstaller la version X.X.X ». WordPress télécharge les fichiers officiels et écrase les fichiers du cœur modifiés, sans toucher à vos contenus, thèmes ou extensions.
Si vous n’avez plus accès au tableau de bord : téléchargez WordPress depuis wordpress.org, supprimez les dossiers wp-admin et wp-includes du serveur, puis envoyez ceux de l’archive officielle par FTP. Un simple envoi par-dessus laisserait en place les fichiers ajoutés par le pirate.
5. Inspecter et restaurer le fichier .htaccess
Le .htaccess est le premier endroit où se cache une redirection pirate. Ouvrez-le via FTP (il est à la racine, fichier masqué, activez l’affichage des fichiers cachés dans FileZilla).
Un .htaccess WordPress standard ne contient que quelques lignes autour de # BEGIN WordPress. Tout le reste est suspect. Si vous voyez des blocs de redirections conditionnelles (vers des sites tiers selon l’user-agent ou le referrer), remplacez le fichier entier par le contenu standard d’un site installé à la racine du domaine :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
6. Supprimer les extensions et le thème, puis les réinstaller depuis leur source officielle
Renommez le dossier /wp-content/plugins en /wp-content/plugins-disabled via FTP. Le site bascule en mode sans extensions actives. Si le comportement suspect disparaît, une extension était compromise.
Réinstallez chaque extension depuis wordpress.org ou sa source officielle, pas depuis une sauvegarde. Une extension piratée dont vous réinstallez l’archive compromise redémarre avec la backdoor intégrée.
Faites la même chose avec le thème actif. Les dossiers des thèmes non utilisés doivent être supprimés entièrement : même désactivés dans le tableau de bord, leurs fichiers PHP restent présents sur le serveur et peuvent être appelés directement.
À retenir
- Une extension installée depuis une source tierce (nulled, téléchargement direct) est une porte d’entrée probable
- Les thèmes enfants héritent parfois du code malveillant du thème parent
- Si vous avez perdu l’accès admin, vous ne pouvez pas supprimer une extension depuis le tableau de bord : supprimez ses fichiers directement via FTP
7. Retirer les articles de spam et chercher d’où ils viennent
Mettez à la corbeille les articles ou pages de spam. Avant de les supprimer définitivement, notez leur date de création, leur auteur assigné, et vérifiez si une adresse externe est glissée dans les métadonnées ou dans un réglage global (Réglages > Général > Tagline, ou un widget de pied de page).
Une adresse extérieure glissée dans un réglage survit à la suppression des articles. C’est la signature d’une injection persistante.
8. Demander une révision à Google si le site est signalé comme dangereux
Si la Search Console affiche un avertissement de sécurité actif, une fois le nettoyage terminé : Sécurité et actions manuelles > Problèmes de sécurité > Demander une révision. Décrivez brièvement les mesures prises. Google traite généralement ces demandes en quelques jours, mais le site reste signalé pendant ce délai.

En pratique
- Les étapes 2 (mots de passe) et 4 (réinstallation cœur) sont parmi les gestes les plus efficaces et les plus rapides à réaliser
- Ne sautez pas l’étape .htaccess : c’est là que se cachent les redirections qui récidivent
- La demande de révision Google n’est utile que si le nettoyage est réellement terminé
Comment savoir que le nettoyage est terminé
Un nettoyage qui semble complet peut laisser une backdoor active. Le signe le plus parlant : le site est de nouveau piraté quelque temps après, par le même vecteur.
| Contrôle | Outil | Résultat attendu |
|---|---|---|
| Scan des fichiers | Wordfence ou Sucuri | Aucun fichier malveillant détecté |
| Search Console | Google Search Console | Aucun avertissement actif |
| Comptes utilisateurs | WordPress admin | Aucun compte inconnu |
| .htaccess | FTP | Contenu standard uniquement |
| DNS | registraire | Pointage inchangé vers l’hébergeur |
Les contrôles à refaire 48 heures après
Relancez un scan complet après un délai suivant le nettoyage, en plus du scan immédiat. Pourquoi pas immédiatement ? Certaines backdoors ont des déclencheurs différés : elles se réactivent après un premier accès, pas au moment de l’installation. Un scan immédiat peut revenir propre alors qu’une tâche planifiée prépare la réinjection.
Vérifiez aussi les tâches planifiées WordPress (avec l’extension WP Crontrol, menu Outils > Cron Events) : une tâche cron injectée peut déclencher une réinfection à heure fixe.
Prévenir les plateformes où le site est en vente
Si le site est référencé sur des marketplaces ou des plateformes de vente d’articles sponsorisés, signalez-leur la compromission passée et sa résolution. Certains acheteurs d’articles vérifient l’historique de sécurité avant de valider une commande. Un rapport de nettoyage documenté vaut mieux qu’un silence qui inquiète.
Les erreurs qui font tout rater
La plupart des récidives ne viennent pas d’un piratage plus sophistiqué. Elles viennent d’une procédure incomplète la première fois.
| Erreur | Conséquence | Alternative |
|---|---|---|
| Remettre en ligne trop tôt | Le pirate garde la main, le site retombe | Attendre un second scan propre, puis demander la révision |
| Changer uniquement le mot de passe WordPress | Le pirate garde l’accès FTP ou BDD | Changer TOUS les accès depuis l’hébergeur |
| Réinstaller une extension depuis une archive locale | Backdoor réintégrée | Toujours depuis wordpress.org |
| Supprimer les articles de spam sans chercher la source | L’injection recommence | Tracer le vecteur avant de nettoyer |
| Ignorer les DNS | Le domaine pointe ailleurs | Vérifier chez le registraire |
Remettre le site en ligne trop tôt
Tant que Google n’a pas validé la révision, le site reste signalé comme dangereux, mais il doit être en ligne et nettoyé pour que Google puisse le vérifier. Les visiteurs voient l’avertissement rouge. Le trafic ne revient pas de lui-même.
Changer uniquement le mot de passe WordPress sans toucher l’hébergeur
C’est l’erreur la plus courante. Elle donne l’impression d’avoir agi alors que l’attaquant conserve un accès FTP fonctionnel. Depuis cet accès FTP, il peut réécrire le .htaccess, déposer un nouveau fichier PHP dans les médias, ou modifier wp-config.php directement.
Si vous ne changez que le mot de passe WordPress, vous fermez une porte en laissant les fenêtres ouvertes.
Variantes selon la gravité de l’intrusion
Tous les piratages ne se traitent pas de la même façon. La gravité conditionne la méthode.
Piratage limité à un fichier : réinstallation ciblée
Un seul fichier .php inconnu dans /wp-content/uploads est fréquent avec les injections via formulaire ou upload non filtré. Supprimez le fichier, vérifiez les permissions du dossier uploads (755 maximum, jamais 777), et réinstallez l’extension qui gère les uploads si elle est impliquée.
Réinstallation ciblée, efficace sur un périmètre précis, mais insuffisante si d’autres fichiers ont été modifiés en amont.
Compromission totale : tout supprimer et repartir d’une sauvegarde saine
Quand plusieurs vecteurs sont touchés simultanément (cœur, extensions, base de données, comptes), la restauration depuis une sauvegarde antérieure au piratage est souvent plus rapide et plus fiable qu’un nettoyage fichier par fichier.
Condition : la sauvegarde doit dater d’avant l’intrusion. Utilisez les logs serveur pour dater le premier accès suspect, votre hébergeur peut vous aider à les interpréter.
Plusieurs sites sur le même hébergeur : isoler chacun d’eux d’urgence
Un piratage sur un hébergement mutualisé peut se propager latéralement aux autres sites du même compte. Si vous gérez un parc de sites sur le même hébergeur, vérifiez chacun d’eux immédiatement, même ceux qui semblent intacts. Le fichier PHP malveillant dans le dossier médias d’un site peut servir de point d’entrée pour les autres.
Ce que les pirates ont modifié sans que vous l’ayez vu venir
Un audit WordPress efficace va au-delà des fichiers visibles. Certaines modifications persistent après un nettoyage de surface.
PHP caché dans le dossier des médias, DNS détournés, réglages empoisonnés
Le dossier /wp-content/uploads n’a aucune raison de contenir des fichiers .php. C’est pourtant l’un des premiers endroits où les pirates déposent leurs outils, parce que ce dossier est en écriture ouverte par défaut et rarement inspecté.
Autres zones souvent ignorées :
- Réglages > Général : une URL externe glissée dans le champ « Tagline » ou « Description du site » reste indexée par Google même après suppression des articles de spam
- Widgets et blocs réutilisables : du code peut y être injecté et persister après nettoyage des pages
- DNS : si votre domaine répond depuis un serveur différent de votre hébergeur, le détournement est avancé. Vérifiez immédiatement chez votre registraire.
- Tâches cron : une tâche planifiée peut réinjecter du contenu à heure fixe sans laisser de trace dans les fichiers
Il arrive que des réglages empoisonnés survivent à plusieurs cycles de nettoyage, parce que personne ne pense à les vérifier. C’est souvent le dernier endroit regardé, et le premier que le pirate utilise pour s’assurer un accès durable.
Surveiller ces signaux en continu avec une veille automatisée
Un nettoyage ponctuel protège jusqu’au prochain fichier vulnérable ou à la prochaine extension obsolète. Gérer un parc de sites sans veille de sécurité automatisée, c’est découvrir l’intrusion en lisant un email de Google, rarement au bon moment.
Pour les éditeurs qui gèrent plusieurs domaines, il est possible de surveiller tous vos sites sur un seul écran et de recevoir une alerte dès qu’un changement suspect est détecté, avant que le dommage soit visible.
| Signal | Fréquence de vérification | Outil |
|---|---|---|
| Fichiers cœur modifiés | Quotidienne | Wordfence, Robinet Shield |
| Comptes administrateurs | À chaque alerte | WordPress admin |
| DNS | Hebdomadaire | Registraire |
| Search Console | Hebdomadaire | Google Search Console |
| Tâches cron | Après chaque nettoyage | WP Crontrol |
Les pièges de la fausse confiance
Une récidive rapide après nettoyage est presque toujours le signe d’une backdoor non détectée, et non d’un attaquant plus habile.
Le scénario se répète : nettoyage des fichiers visibles, changement du mot de passe WordPress, remise en ligne. Quelque temps plus tard, les mêmes pages de spam réapparaissent. La backdoor était dans un fichier image renommé .php, dans un sous-dossier du dossier médias que personne n’avait ouvert.
Un audit complet couvre ces zones invisibles. Si vous avez un doute sur la complétude du nettoyage, des prestataires spécialisés proposent ce service.
Questions fréquentes
Mon hébergeur peut-il nettoyer le site à ma place ?
La plupart des hébergeurs proposent une restauration de sauvegarde, mais pas un audit de sécurité ni un nettoyage de backdoor. Ils remettront votre site dans l’état d’une date antérieure, ce qui est utile si vous avez une sauvegarde saine, mais ne ferme pas la faille qui a permis l’intrusion. Le nettoyage actif reste à votre charge ou à celle d’un prestataire spécialisé.
Le piratage affecte-t-il le référencement de façon permanente ?
Non, à condition d’agir vite et de valider la révision Google. Un site signalé comme dangereux voit son trafic chuter brutalement, mais la pénalité est levée après validation de la demande de révision dans la Search Console. Plus le site reste signalé longtemps, plus le retour à la normale prend de temps : quelques jours à quelques semaines selon l’ancienneté du signal.
Comment savoir depuis quelle version de plugin le piratage s’est produit ?
Les logs d’accès serveur (access.log) conservent les requêtes HTTP avec leur timestamp. Cherchez les requêtes POST inhabituelles vers des fichiers d’extensions, ou des accès à des URLs qui n’existent pas dans votre installation. Votre hébergeur peut vous aider à interpréter ces logs si vous n’êtes pas à l’aise avec leur format.
Un site WordPress piraté se nettoie, mais la vraie erreur à ne pas commettre, c’est de considérer le nettoyage comme terminé après avoir changé le mot de passe et supprimé les articles de spam.
Vérifiez le .htaccess, les tâches cron, les réglages globaux et le dossier des médias avant de remettre le site en ligne. C’est là que la récidive se prépare.
Lancez un scan complet du site avec Wordfence ou Sucuri dès maintenant, avant de toucher à quoi que ce soit d’autre. Ce scan vous donnera une carte des modifications, et c’est depuis cette carte que tout le reste s’organise.