Mon site WordPress est piraté : guide d’urgence étape par étape

Voir son site WordPress piraté provoque la même sensation que rentrer chez soi et trouver la porte fracturée. On se sent dépossédé, un peu coupable, et surtout pressé de tout remettre en état sans aggraver les dégâts. Pourtant, la précipitation est souvent l’alliée du pirate, pas la vôtre.

Ce guide est pensé pour le moment où vous tapez fébrilement “urgence WordPress piraté” dans un moteur de recherche, avec un onglet de votre site ouvert qui affiche des contenus douteux ou une page blanche. L’objectif est d’avancer de façon structurée, même si le stress est là.

Je pars d’un principe simple : vous n’êtes pas forcément développeur ou administrateur système, mais vous gérez un site WordPress en production, avec des enjeux réels, même modestes. Vous trouverez donc à la fois des gestes simples et des repères plus techniques pour dialoguer avec un prestataire si besoin.

D’abord, comprendre ce qui se passe vraiment

Un site piraté ne se manifeste pas toujours clairement. Parfois, la seule alerte vient d’un email de votre hébergeur ou de Google Search Console. D’autres fois, la page d’accueil affiche sans détour une arnaque ou une redirection vers un site de phishing.

Les symptômes les plus fréquents sont variés : publicités douteuses, redirections aléatoires sur mobile, création d’utilisateurs inconnus dans WordPress, nouveaux fichiers suspects sur le serveur, baisse brutale du trafic organique, ou encore avertissement de sécurité dans le navigateur.

Il faut garder une chose en tête : ce que vous voyez n’est souvent que la partie visible. Un pirate qui Jetez un œil sur ce site ici prend la peine de se cacher laisse parfois un site “apparemment normal” pour exploiter discrètement votre serveur pour l’envoi de spam, le minage de cryptomonnaies ou l’hébergement de pages de phishing invisibles pour un visiteur classique.

Ce décalage entre symptômes et réalité explique pourquoi les actions impulsives comme “tout supprimer pour repartir à zéro” ou “installer un plugin miracle trouvé au hasard” peuvent faire plus de mal que de bien.

Les tout premiers gestes à faire en urgence

Lorsque le constat tombe, il faut à la fois contenir les dégâts et préserver un maximum d’informations pour la suite. La phase de gel de la situation est essentielle.

Voici un premier plan d’action, à suivre dans cet ordre plutôt que dans tous les sens.

Mettre le site hors ligne proprement

Si votre hébergeur propose un mode maintenance ou la désactivation temporaire du virtualhost, utilisez cette option. Sinon, vous pouvez mettre en place une simple page statique via .htaccess ou via l’interface d’administration de l’hébergeur. L’idée est que le public ne voie plus l’attaque, même si elle est encore dans les fichiers. Évitez les plugins de maintenance tant que vous n’avez pas repris le contrôle, car installer un nouveau plugin sur un système compromis revient à bricoler une serrure sur une porte déjà fracturée.

Changer immédiatement certains mots de passe

Commencez par le mot de passe du compte principal chez l’hébergeur (accès au panneau type cPanel, Plesk ou interface maison). Ensuite, changez les accès FTP / SFTP et les comptes administrateurs WordPress connus. Ne faites pas l’économie d’un vrai générateur de mots de passe. Attendez un peu pour les mots de passe de la base de données, car cela implique une mise à jour du fichier wp-config.php et vous pouvez avoir besoin d’un accès stable quelques minutes de plus pour faire des sauvegardes.

Faire une sauvegarde complète telle qu’elle est

Même si le site est infecté, il est très utile d’en garder une image à des fins d’analyse. Copiez tous les fichiers (WordPress, thèmes, plugins, uploads) ainsi que la base de données. Si l’hébergeur propose des sauvegardes automatiques, notez immédiatement la date et l’heure des derniers snapshots disponibles. Beaucoup de propriétaires de sites regrettent plus tard de ne pas avoir gardé une trace de l’état compromis, ne serait-ce que pour comprendre d’où vient l’attaque et ajuster ensuite les protections.

Vérifier rapidement si d’autres sites sur le même hébergement sont touchés

Sur les hébergements mutualisés ou les VPS avec plusieurs sites, un seul piratage peut être la porte d’entrée vers les autres. Prenez quelques minutes pour vous connecter en SFTP et jeter un œil aux répertoires voisins. S’il y a des fichiers au nom étrange dans plusieurs dossiers, le problème est peut-être plus large que votre seul WordPress.

Geler les actions marketing critiques

Si vous remplissez des formulaires, envoyez des newsletters, encaissez des paiements, mieux vaut suspendre temporairement les opérations sensibles. Un simple lien compromis dans un email envoyé à plusieurs milliers de personnes peut transformer un incident “local” en cauchemar réputationnel.

Ces cinq gestes servent à sécuriser le périmètre immédiat sans encore entrer dans la chirurgie du site. Ils gagnent du temps et limitent l’ampleur des dégâts.

Faire le point sur l’ampleur de l’attaque

Une fois le site hors ligne pour le grand public et les accès critiques sécurisés, le temps de la photographie plus précise arrive. L’objectif n’est pas d’avoir un rapport forensique complet, mais de répondre à quelques questions clés.

La première : l’attaque concerne-t-elle uniquement WordPress ou potentiellement l’hébergement tout entier ? Pour cela, quelques indices comptent. Si vous trouvez des scripts PHP suspects dans des répertoires hors du dossier du site (par exemple dans d’autres comptes ou dans /tmp si vous y avez accès), l’attaque est probablement plus large. De même, si l’hébergeur a désactivé tout votre compte et non un seul site, prenez cette alerte au sérieux.

La deuxième concerne le type d’exploitation. La plupart des piratages WordPress que je vois sur des petits et moyens sites relèvent de scénarios récurrents : plugin ou thème vulnérable, mot de passe administrateur trop faible et deviné par force brute, absence de mise à jour de WordPress lui-même, ou encore réutilisation d’un mot de passe déjà compromis sur un autre service.

On peut déjà chercher quelques éléments simples :

    Date approximative de la première anomalie (via les backups de l’hébergeur, Google Analytics, Search Console, ou les emails d’alerte) Connexions étranges au back-office WordPress (adresses IP atypiques, connexions à des heures improbables) Fichiers récemment modifiés sur le serveur à des dates où vous n’avez rien déployé

Beaucoup d’hébergeurs proposent une vue des fichiers modifiés récemment. C’est une mine d’informations, avec prudence : les pirates savent parfois antidater des fichiers ou se cacher dans des dossiers très verbeux comme wp-content/uploads.

Restaurer une sauvegarde ou nettoyer à la main ?

Face à une urgence WordPress piraté, le réflexe logique est de se dire “je vais restaurer une sauvegarde et tout ira bien”. C’est parfois la meilleure solution, mais pas toujours.

image

Restaurer un snapshot complet fonctionne bien lorsque plusieurs conditions sont réunies. D’abord, vous avez des sauvegardes fiables, idéalement datées et vérifiables. Ensuite, vous êtes raisonnablement certain que la compromission n’existait pas encore à la date que vous ciblez. Enfin, vous acceptez de perdre les contenus ajoutés après cette date, ou vous savez comment les réinjecter proprement.

Par exemple, un site vitrine avec peu de changements peut revenir à un snapshot de deux semaines sans grande conséquence. À l’inverse, un site e‑commerce avec des commandes quotidiennes ne peut pas se permettre de perdre dix jours de données.

Si vous choisissez la restauration, prenez le temps de :

    Restaurer d’abord dans un environnement de test si l’hébergeur le permet Mettre à jour immédiatement WordPress, les thèmes et les plugins après la restauration Rechanger tous les mots de passe, même si la sauvegarde semble saine Effectuer un scan de sécurité après la remise en ligne

Le nettoyage manuel arrive plutôt dans deux cas : soit les sauvegardes sont absentes, soit elles sont probablement infectées elles aussi. On voit souvent des sites où l’intrusion date de plusieurs mois, avec des scripts dormants utilisés à la demande par les pirates. Restaurer une sauvegarde de trois semaines dans ce contexte ne règle rien.

Le nettoyage consiste alors à repartir de sources saines pour le cœur de WordPress, les thèmes et les plugins, puis à passer au peigne fin les fichiers qui restent, en particulier dans wp-content/uploads et dans les éventuels répertoires personnalisés.

Repartir d’un WordPress sain sans tout effacer

Une approche relativement robuste, qui fonctionne bien dans la plupart des incidents, consiste à considérer que tous les fichiers WordPress “noyau” sont potentiellement compromis, de même que les plugins et thèmes, mais que la base de données et les fichiers médias doivent être sauvés autant que possible.

Concrètement, la démarche ressemble à ceci.

On commence par supprimer tous les fichiers WordPress via SFTP ou le gestionnaire de fichiers de l’hébergeur, à l’exception du répertoire wp-content et du fichier wp-config.php. Dans wp-content, on supprime les dossiers plugins et themes pour repartir de versions propres, en gardant uniquement uploads et les éventuels répertoires spécifiques développés sur mesure si on en connaît bien le contenu.

On télécharge ensuite depuis wordpress.org une version officielle de WordPress, que l’on décompresse en local, puis que l’on envoie sur le serveur à la place de l’ancienne. Cette opération remplace tous les fichiers de base par des versions propres.

Vient ensuite le cas délicat des thèmes et plugins. Il faut résister à la tentation de tout remettre “comme avant” en bloc. On réinstalle uniquement les extensions dont on a réellement besoin, depuis le dépôt officiel ou depuis les sources du développeur, mais jamais depuis un zip trouvé sur un site de téléchargement douteux.

À ce stade, la base de données n’a pas été touchée. Les articles, pages, options et comptes utilisateurs sont toujours là. Si le pirate a créé des comptes administrateurs factices, ils apparaîtront dans la liste des utilisateurs. Il faudra les supprimer ou les rétrograder plus tard.

Une fois la structure logicielle reconstruite à partir de sources saines, on peut reconnecter le site à la base existante via wp-config.php (ou vérifier que ce fichier pointe toujours vers la base voulue) et tester le fonctionnement en mode maintenance, en limitant l’accès à votre propre IP si possible.

image

Nettoyer la base de données et les utilisateurs

Beaucoup d’attaques WordPress ne se limitent pas aux fichiers. Il arrive fréquemment qu’un pirate injecte des scripts dans les contenus eux‑mêmes ou modifie des options dans la base.

Les formes classiques que l’on rencontre :

Des iframes ou scripts malveillants ajoutés en bas des articles ou des pages. On peut parfois les repérer en exportant la base puis en cherchant des fragments récurrents de code JavaScript obfusqué.

Des redirections installées via l’option siteurl, via des plugins transformés en portes dérobées, ou via des règles stockées dans la base. Par exemple, un visiteur mobile peut être redirigé vers un site d’arnaque alors qu’un visiteur sur ordinateur voit encore le contenu normal.

Des comptes administrateurs nouveaux, avec des noms d’utilisateur anodins comme “support”, “wp-admin” ou “seo”. Ce sont souvent des portes de secours qui permettent au pirate de revenir même après nettoyage des fichiers.

Pour cette phase, un accès direct à la base via phpMyAdmin ou un équivalent est souvent nécessaire. On peut aussi utiliser des plugins de sécurité capables de lister les comptes aux droits élevés et de repérer des entrées suspectes dans certaines tables, mais rien ne remplace une vérification humaine quand c’est possible.

Sur un incident réel que j’ai suivi, le pirate avait créé un compte administrateur nommé simplement “blog”, qui ne ressortait pas immédiatement comme suspect dans une liste de plusieurs dizaines d’utilisateurs. La seule façon de le repérer a été de filtrer par date de création et de regarder ce qui avait été ajouté la semaine de l’attaque.

Idéalement, on profite de cette phase pour revoir complètement la liste des administrateurs. Beaucoup de sites WordPress cumulent les comptes obsolètes : anciens prestataires, stagiaires, développeurs qui n’ont plus aucune raison d’avoir un accès complet. C’est le moment de faire le ménage.

S’appuyer sur des outils de sécurité sans s’y abandonner

Certains plugins de sécurité rendent de vrais services dans une situation d’urgence. Ils peuvent aider à détecter des fichiers modifiés, comparer le cœur de WordPress avec les versions officielles, renforcer l’authentification et signaler des comportements anormaux.

Il faut cependant garder une distance critique. Aucun plugin ne compensera des mots de passe faibles, un thème piraté obtenu gratuitement alors qu’il est normalement payant, ou une politique de mise à jour inexistante.

Dans un contexte d’incident, je m’en sers principalement pour trois choses. D’abord, un scan de comparaison des fichiers du noyau de WordPress pour repérer rapidement les altérations. Ensuite, une revue des permissions de fichiers et de dossiers, car certains hébergeurs laissent le tout un peu trop ouvert, ce qui facilite les écritures non autorisées par un attaquant. Enfin, un durcissement basique après remise en ligne, avec limitation du nombre de tentatives de connexion et journalisation plus détaillée.

Sur des sites très sensibles, ces mesures complètent mais ne remplacent pas un audit de code, un WAF (web application firewall) géré en amont, ou une architecture plus cloisonnée. Pour un site de taille modeste, bien configuré, elles offrent déjà un bon niveau de résilience.

Quand faire appel à un professionnel, et comment le choisir

Personne n’a honte d’appeler un serrurier après un cambriolage. Pour un WordPress piraté, le réflexe reste souvent de tout faire seul, faute de savoir à qui s’adresser ou par peur des coûts. Pourtant, une intervention professionnelle rapide peut réduire fortement la durée d’indisponibilité et limiter les dégâts sur l’image.

Il y a quelques signaux qui, selon mon expérience, justifient presque toujours d’appeler un expert : un site e‑commerce avec paiements en ligne, un site institutionnel très visible, toute situation où des données personnelles sensibles peuvent avoir été exposées, ou encore une récidive après un premier nettoyage “maison”.

Le choix du prestataire se fait moins sur un beau discours que sur quelques indicateurs concrets. Demandez systématiquement ce qu’il compte vérifier en priorité, s’il prévoit un rapport de fin d’intervention, et quelles mesures de prévention il propose après nettoyage. Un bon professionnel explique ce qu’il fait de manière compréhensible, sans vendre du mystère.

Sur le plan pratique, clarifiez aussi le périmètre : inclut‑il l’analyse des logs serveur si disponibles, la coordination avec l’hébergeur, une aide au retrait d’éventuels avertissements dans Google, ou simplement un nettoyage de fichiers et base ? Un forfait pas cher qui ne couvre que l’aspect “cosmétique” vous replongera parfois dans la même urgence quelques semaines plus tard.

Gérer l’image, les visiteurs et les clients

On se concentre naturellement sur la partie technique, mais un incident de sécurité est aussi une épreuve de communication. Les personnes qui utilisent votre site n’ont pas les détails techniques, mais elles perçoivent immédiatement si vous faites comme si de rien n’était.

Sur un petit site vitrine, un simple message de maintenance bien rédigé, transparent sans entrer dans les détails, peut suffire : expliquer que le site est temporairement indisponible pour raison de sécurité, que des mesures de protection renforcée sont en cours, et proposer un canal de contact alternatif (téléphone, email direct, page LinkedIn, etc.).

Sur un site qui manipule des données personnelles ou des paiements, la question devient plus sensible. Selon le pays et le secteur d’activité, des obligations légales d’information existent. Même lorsqu’elles ne sont pas strictement obligatoires, informer les clients concernés en cas de risque sérieux sur leurs données reste un acte de responsabilité.

J’ai vu des sites choisir le silence en espérant que l’incident passe inaperçu, pour finalement se retrouver exposés publiquement par un client plus technophile ou par un message d’alerte du navigateur. À ce stade, la perte de confiance est souvent plus difficile à réparer que les dégâts techniques.

La clé reste d’adapter le niveau de détail à votre audience. L’utilisateur n’a pas besoin de savoir quel plugin a servi de porte d’entrée, mais il a besoin de savoir si ses informations de paiement ont pu être compromises et ce qu’il peut faire pour se protéger.

Renforcer durablement la sécurité après l’incident

Une fois la crise immédiate passée, vient le moment, moins spectaculaire mais décisif, de transformer l’expérience en progrès durable. C’est là que beaucoup de sites ratent une occasion d’élever franchement leur niveau de sécurité.

Les axes classiques de renforcement peuvent tenir dans une courte feuille de route.

Hygiène des mises à jour et des plugins

La plupart des compromissions via WordPress que j’ai vues auraient pu être évitées par une simple politique de mise à jour régulière. Mettre à jour le cœur, les plugins et les thèmes au moins une fois par semaine sur un site actif, c’est déjà fermer la porte à un bon nombre d’attaques opportunistes. Cela implique aussi de limiter la prolifération de plugins. Chaque extension supplémentaire est une surface d’attaque de plus. Supprimez ceux qui ne servent plus ou qui doublonnent des fonctions disponibles dans le thème.

Gestion stricte des comptes et mots de passe

Généraliser les mots de passe robustes et uniques, idéalement gérés par un gestionnaire dédié, change radicalement la donne. L’activation d’une double authentification pour les comptes administrateurs est aujourd’hui un standard raisonnable. Sur les petits sites, donner un compte administrateur à tout le monde “pour simplifier” est une erreur fréquente. La plupart des rédacteurs n’ont pas besoin d’accéder aux réglages critiques.

Cloisonnement de l’hébergement

Sur un hébergement mutualisé avec plusieurs sites dans le même compte, un seul site compromis peut servir de tremplin vers les autres. Quand c’est possible, séparer les sites sensibles dans des comptes distincts, voire sur des serveurs différents, réduit nettement les risques de propagation. Pour des projets professionnels, un VPS correctement géré ou une offre managée plus sérieuse que l’entrée de gamme mutualisée se justifie rapidement.

Sauvegardes testées et scénarios d’urgence

Avoir des sauvegardes est une chose, savoir les restaurer en est une autre. Programmer un test de restauration complet une ou deux fois par an permet de vérifier que les sauvegardes sont réellement exploitables. Documenter un scénario d’urgence WordPress piraté, même en deux pages, permet aussi d’agir beaucoup plus rapidement le jour où un incident survient.

Surveillance et alertes

Mettre en place quelques alertes simples change la vitesse de réaction. Une notification en cas de création d’un nouvel administrateur, un monitoring de disponibilité du site, une alerte en cas de modification de fichiers système, ou encore un suivi de l’apparition de pages suspectes dans l’index de Google servent d’early warning.

Cette phase de consolidation n’empêche jamais totalement les attaques, mais elle les rend plus difficiles et augmente vos chances de repérer rapidement une anomalie avant qu’elle ne prenne de l’ampleur.

Garder la tête froide pour sortir plus solide de l’incident

Un piratage WordPress est désagréable, parfois humiliant, souvent stressant. Pourtant, avec un minimum de méthode, il devient gérable. L’urgence WordPress piraté n’a pas besoin de se transformer en panique si l’on suit quelques principes : sécuriser rapidement l’accès, conserver des preuves suffisantes, nettoyer proprement plutôt que bricoler, puis tirer des conséquences concrètes sur la manière dont le site est géré.

La plupart des petites structures n’ont pas un service informatique complet, mais elles peuvent adopter des habitudes de base inspirées de ce que font les acteurs plus gros : mises à jour régulières, séparation des rôles, sauvegardes vérifiées, et un minimum de documentation interne sur qui a accès à quoi.

Le jour où l’incident survient, on découvre vite que ces quelques heures investies en amont valent largement le temps passé à courir après un site compromis en pleine activité. Une fois la tempête passée, le meilleur indicateur de réussite reste simple : vous dormez à nouveau correctement la nuit, et votre site continue de travailler pour vous sans que vous ayez l’impression de marcher sur un fil.