Site WordPress piraté : que faire ?

Votre site affiche une redirection inconnue, une page de phishing, un compte administrateur suspect ou un autre signe sérieux de compromission ? Lorsqu’un site WordPress est piraté, les premières minutes comptent surtout pour éviter deux erreurs : aggraver l’incident et faire disparaître les informations qui permettront de comprendre ce qui s’est passé.

La priorité n’est pas de supprimer immédiatement un fichier, de lancer plusieurs scanners ou de restaurer la première sauvegarde disponible. Il faut d’abord figer la situation, documenter les symptômes, préserver les sauvegardes et les journaux, vérifier les fonctions critiques du site puis qualifier le niveau d’urgence.

Cette ressource est conçue comme un plan d’action pour les 30 premières minutes. Si vous n’êtes pas encore certain qu’il s’agit d’un piratage, commencez plutôt par le guide Comment savoir si mon site WordPress est piraté ?. Si le signal vient directement de votre hébergeur, consultez également la procédure dédiée aux alertes de malware et suspensions d’hébergement.

Avant d’agir : piratage confirmé ou simple suspicion ?

Ce guide part du principe qu’un piratage est confirmé ou suffisamment probable pour déclencher une réponse d’urgence. C’est notamment le cas lorsque vous observez l’un des signaux suivants :

• une redirection vers un domaine inconnu ;
• une page de phishing ou un contenu que vous n’avez pas créé ;
• un compte administrateur non autorisé ;
• des fichiers malveillants signalés par l’hébergeur ou un outil de sécurité ;
• des e-mails indésirables envoyés depuis l’hébergement ;
• des pages spam apparues dans Google ;
• une alerte de sécurité affichée par Google ou le navigateur.

Une erreur 500, une page blanche, une lenteur ou un back-office inaccessible peuvent aussi provenir d’un conflit d’extension, d’une mise à jour défectueuse ou d’un problème d’hébergement. Lorsque le seul signal est un dysfonctionnement technique apparu juste après une intervention connue, le diagnostic doit rester ouvert.

La différence est importante : l’article présent explique quoi faire lorsque le risque est déjà sérieux. Le guide de détection aide, lui, à déterminer si les symptômes correspondent réellement à une compromission.

0 à 5 minutes : rester calme et geler les changements

La première mesure consiste à empêcher que vos propres actions ne compliquent l’analyse. Notez l’heure exacte à laquelle vous avez découvert le problème, puis suspendez les interventions qui ne sont pas indispensables.

Dans l’immédiat, évitez de :

• mettre à jour WordPress, les extensions ou le thème dans l’espoir que le problème disparaisse ;
• supprimer un fichier uniquement parce que son nom semble inhabituel ;
• réinstaller WordPress par-dessus l’installation actuelle ;
• restaurer une sauvegarde sans connaître sa date et son état ;
• installer plusieurs plugins de sécurité ou lancer des corrections automatiques ;
• modifier en même temps les DNS, le cache, le thème et la configuration serveur.

Ces actions peuvent modifier les dates de fichiers, écraser des traces, créer une panne supplémentaire ou donner l’impression que le problème a disparu alors qu’un mécanisme de persistance est toujours actif.

5 à 10 minutes : documenter précisément les symptômes

Un incident est plus facile à qualifier lorsque les faits sont datés et décrits précisément. Ne vous contentez pas de noter « le site a été piraté ». Indiquez ce que vous avez réellement observé.

• l’URL exacte concernée ;
• la date, l’heure et le fuseau horaire ;
• le message d’erreur ou d’alerte dans son intégralité ;
• le navigateur, l’appareil et le réseau utilisés ;
• la provenance du visiteur : accès direct, Google, e-mail, publicité ou autre ;
• le caractère permanent ou intermittent du symptôme ;
• les modifications ou mises à jour réalisées récemment ;
• les personnes qui ont eu accès au site dans les jours précédents.

Conserver des captures sans multiplier les visites

Prenez une capture de la page, de la barre d’adresse, de l’alerte reçue et, si possible, de l’heure affichée. Si le problème est intermittent, un test depuis une navigation privée ou un mobile peut aider à le confirmer. Évitez toutefois de visiter plusieurs fois une page de phishing ou de saisir des données dans un formulaire suspect.

Conserver les messages originaux

Gardez les e-mails et tickets de l’hébergeur, de Google Search Console, des outils de sécurité et des clients. Le texte exact, les chemins de fichiers, les URL et les horodatages ont plus de valeur qu’un résumé rédigé de mémoire.

10 à 15 minutes : préserver les sauvegardes et les traces utiles

Une sauvegarde peut permettre une restauration, servir de point de comparaison ou aider à dater l’apparition de l’infection. Elle ne doit toutefois pas être considérée comme saine uniquement parce qu’elle est antérieure à la découverte du problème.

Identifier ce qui existe déjà

Relevez les sauvegardes disponibles auprès de l’hébergeur, dans les outils de maintenance et sur les éventuels stockages externes. Pour chacune, notez :

• la date et l’heure ;
• la présence des fichiers et de la base de données ;
• le lieu de stockage ;
• la durée de conservation ;
• la possibilité réelle de la restaurer.

Évitez de lancer une nouvelle sauvegarde qui remplacerait la plus ancienne copie disponible. Vérifiez d’abord la politique de rétention et, lorsque cela est possible, protégez les points de restauration existants contre l’écrasement automatique.

Conserver un état actuel lorsque c’est possible

Une copie de l’état compromis peut être utile avant nettoyage. Elle doit être clairement identifiée comme potentiellement infectée, stockée séparément et ne jamais être remise en production sans vérification. Si vous ne maîtrisez pas la création d’un snapshot ou d’une copie complète, demandez à l’hébergeur de préserver l’état actuel.

Préserver les journaux

Les journaux d’accès, d’erreurs, de connexions, d’exécution PHP et d’envoi d’e-mails peuvent aider à reconstituer la chronologie. Leur durée de conservation est parfois courte. Notez leur emplacement et demandez une copie à l’hébergeur avant qu’ils ne soient automatiquement purgés.

15 à 20 minutes : vérifier les fonctions critiques du site

Le niveau d’urgence dépend autant de la nature technique du piratage que de son impact sur l’activité. Vérifiez les fonctions essentielles sans effectuer d’actions risquées ni saisir de données sensibles sur une page suspecte.

Zone à vérifier	Questions à se poser	Signal préoccupant
Site public	Les pages principales s’affichent-elles normalement ?	Redirection, contenu inconnu, téléchargement ou alerte navigateur
Administration	L’accès fonctionne-t-il et les administrateurs sont-ils connus ?	Compte inconnu, mot de passe modifié ou réglage de sécurité altéré
Formulaires	Les demandes arrivent-elles encore au bon destinataire ?	Envoi vers une adresse inconnue, spam massif ou absence soudaine de demandes
WooCommerce et paiements	Les moyens de paiement, commandes et pages de validation sont-ils inchangés ?	Passerelle inconnue, script ajouté ou coordonnées bancaires modifiées
E-mails	Les messages transactionnels partent-ils normalement ?	Blocage PHP, volume inhabituel, retours de spam ou réputation dégradée
Google et SEO	Des pages inconnues, alertes ou titres suspects apparaissent-ils ?	Spam indexé, alerte de sécurité ou redirections visibles depuis Google

Pour une boutique, un espace client ou un site de réservation, ne réalisez pas un véritable paiement pour tester. Vérifiez les réglages, les scripts et les événements récents, ou faites contrôler le parcours dans un environnement sécurisé.

20 à 25 minutes : qualifier le niveau d’urgence

Tous les incidents doivent être traités, mais ils ne nécessitent pas tous la même réaction immédiate. Utilisez l’impact sur les visiteurs, les données et l’activité pour déterminer la priorité.

Niveau	Exemples	Action prioritaire
Critique	Phishing actif, redirection, tunnel de paiement altéré, données potentiellement exposées, site utilisé pour attaquer ou tromper des tiers	Limiter immédiatement l’exposition et déclencher une prise en charge
Élevé	Administrateur inconnu, fichiers malveillants confirmés, e-mails PHP bloqués, pages spam, alertes répétées ou réinfection	Préserver les éléments disponibles et lancer un diagnostic prioritaire
À confirmer rapidement	Anomalie isolée, comportement intermittent ou erreur apparue après une mise à jour sans autre indicateur	Documenter, vérifier les signaux complémentaires et ne pas conclure trop vite

Faut-il mettre le site hors ligne ?

La mise hors ligne est justifiée lorsqu’un visiteur risque d’être redirigé, trompé, infecté ou amené à transmettre des données à un tiers. Elle peut également être nécessaire si le paiement ou l’espace client sont susceptibles d’avoir été modifiés.

Lorsque le site ne présente pas de danger visible et que le piratage reste à confirmer, une coupure immédiate n’est pas toujours indispensable. Elle doit être décidée en fonction du risque métier, de la capacité à isoler uniquement la zone concernée et des besoins du diagnostic.

Faut-il changer les mots de passe immédiatement ?

Si un compte a été utilisé sans autorisation ou si une intrusion active est probable, sécurisez les accès prioritaires depuis un appareil fiable : hébergement, comptes administrateurs WordPress, SFTP ou SSH et messagerie associée. Utilisez des mots de passe uniques et activez la double authentification lorsqu’elle est disponible.

Ne changez pas le mot de passe de la base de données sans adapter la configuration de WordPress. Ne transmettez jamais les nouveaux identifiants dans un formulaire de contact ou dans un e-mail non sécurisé.

25 à 30 minutes : préparer les informations nécessaires au diagnostic

Une demande structurée permet de qualifier plus vite l’incident et d’éviter les échanges inutiles. Préparez les éléments suivants :

• l’URL du site et le type de site : vitrine, WooCommerce, réservation, extranet ou autre ;
• le nom de l’hébergeur ;
• la date et l’heure du premier symptôme connu ;
• les URL, captures et messages d’alerte ;
• l’état du site public et de l’administration ;
• l’impact sur les formulaires, commandes, paiements, réservations ou e-mails ;
• les modifications, mises à jour et interventions récentes ;
• les sauvegardes connues et leurs dates ;
• les accès encore disponibles, sans communiquer les mots de passe ;
• les actions déjà tentées depuis la découverte.

Si l’alerte vient de votre hébergeur

Un hébergeur peut signaler un fichier suspect, bloquer les envois PHP, mettre une ressource en quarantaine ou suspendre temporairement le site. Son message constitue un élément important, mais il n’identifie pas toujours toute la compromission ni son point d’entrée.

Conservez le message complet, les chemins de fichiers, l’horodatage et les mesures déjà prises. Ne vous contentez pas de supprimer le seul fichier mentionné. La procédure complète est détaillée dans le guide Mon hébergeur signale un malware ou suspend mon site WordPress : que faire ?.

Que se passe-t-il après les 30 premières minutes ?

La première demi-heure sert à stabiliser la situation et à préparer la réponse. Elle ne remplace ni le diagnostic ni le nettoyage. La suite dépend des résultats obtenus, mais elle comprend généralement cinq étapes.

1. Qualifier l’incident : confirmer les zones touchées, la chronologie probable et l’impact métier.
2. Contenir le risque : limiter les accès non autorisés, isoler les pages dangereuses et protéger les visiteurs.
3. Nettoyer l’ensemble du périmètre : fichiers, base de données, utilisateurs, tâches planifiées, redirections et mécanismes d’envoi.
4. Corriger la cause probable : composant vulnérable, identifiant compromis, mauvaise configuration ou accès ancien.
5. Sécuriser et surveiller : durcissement des accès, sauvegardes, mises à jour contrôlées, surveillance et suivi SEO éventuel.

Pour comprendre le traitement technique, consultez le guide Nettoyer un site WordPress piraté et la prestation de nettoyage malware WordPress. Si Google affiche des pages parasites ou une alerte, un contrôle du SEO après piratage peut également être nécessaire.

Questions fréquentes

Mon site fonctionne encore : est-ce vraiment urgent ?

Oui, si un autre indicateur sérieux est présent. Une infection peut ne toucher que certains visiteurs, fonctionner uniquement depuis Google, créer des pages parasites ou utiliser l’hébergement pour envoyer des e-mails sans modifier la page d’accueil.

Dois-je supprimer le fichier signalé ?

Pas avant d’avoir conservé les informations utiles et vérifié son rôle. Le fichier peut être malveillant, mais il peut aussi n’être qu’une conséquence visible d’une compromission plus large. Sa suppression seule ne prouve pas que le site est sain.

Dois-je restaurer immédiatement une sauvegarde ?

Non. Vérifiez sa date, son contenu et la possibilité de la restaurer. Une sauvegarde peut déjà contenir l’infection. Même lorsqu’elle est propre, elle ne corrige pas automatiquement le point d’entrée qui a permis le piratage.

Faut-il couper le site immédiatement ?

Coupez ou isolez le site si les visiteurs risquent d’être redirigés, trompés, infectés ou amenés à transmettre des données sur une page compromise. Pour une anomalie encore incertaine sans danger visible, la décision dépend du risque métier et des besoins du diagnostic.

Un plugin de sécurité peut-il régler le problème ?

Un plugin peut détecter certains fichiers ou comportements, mais il ne couvre pas nécessairement la base de données, les comptes, les accès à l’hébergement, les tâches serveur, les journaux et les traces visibles dans Google. Il constitue un outil de diagnostic, pas une garantie de nettoyage complet.

Quels mots de passe dois-je changer ?

Lorsque la compromission est probable, sécurisez depuis un appareil fiable les accès à l’hébergement, les comptes administrateurs WordPress, les accès SFTP ou SSH et la messagerie liée au site. Les autres accès doivent être traités selon le périmètre de l’incident. Les mots de passe devront parfois être renouvelés une nouvelle fois après nettoyage.

Quels accès faut-il transmettre pour un diagnostic ?

La première qualification peut commencer avec l’URL, les symptômes, les alertes, l’état du site et les sauvegardes disponibles. Les accès WordPress, hébergement, SFTP, base de données ou Search Console ne doivent être demandés qu’ensuite, par un canal adapté et pour une durée limitée.

Combien de temps faut-il pour remettre le site en état ?

La durée dépend de la taille du site, du type de compromission, des accès disponibles, de la qualité des sauvegardes et des fonctions métier touchées. Une qualification initiale est nécessaire avant d’estimer le travail de nettoyage, de restauration, de sécurisation et de contrôle.