Un site WordPress piraté, ce n’est pas seulement un problème technique. C’est un mélange de stress, de perte de temps, de risque juridique et d’image abîmée, parfois en quelques heures. Quand on vit sa première vraie urgence WordPress piraté, on réalise à quel point tous les accès autour du site sont liés et vulnérables.
La tentation est forte de se concentrer sur un seul problème visible, par exemple un fichier infecté ou un plugin douteux. Pourtant, ce qui limite réellement les dégâts, c’est la capacité à réinitialiser rapidement et proprement tous les accès sensibles. C’est ce volet-là que la plupart des tutos sous-estiment, alors que c’est souvent lui qui évite la deuxième, puis la troisième réinfection.
Dans cet article, on va prendre la situation comme elle vient : le site est compromis, vous êtes en urgence, et votre objectif est clair, reprendre le contrôle et fermer toutes les portes, en profondeur.
Comprendre l’urgence : pourquoi réinitialiser tous les accès
Quand un WordPress est piraté, on pense souvent au mot de passe administrateur. C’est une partie du problème, rarement la totalité. Dans la majorité des incidents que j’ai vus, l’attaquant a cherché à obtenir au moins un des éléments suivants :
- Un accès persistant au serveur (FTP, SFTP, SSH, gestionnaire de fichiers de l’hébergeur) L’accès à la base de données Un compte administrateur WordPress caché ou déguisé Une porte de sortie via un plugin, un thème ou un script externe Des clés ou tokens d’API (par exemple pour un service de paiement ou d’emailing)
Tant que ces accès ne sont pas réinitialisés, vous restez dans la situation la plus dangereuse : vous nettoyez, l’attaquant revient tranquillement par une autre porte.
On ne sait pas toujours ce que l’attaquant a réellement vu ou copié. Par précaution, il faut partir du principe que tout ce qui était stocké en clair sur le serveur a pu être exfiltré. C’est précisément pour cela que la réinitialisation large des accès n’est pas une option, c’est le cœur de la réponse.
Avant tout : contenir les dégâts sans tout casser
La première réaction compte énormément. Elle doit être rapide, mais pas paniquée. Il y a trois objectifs immédiats : empêcher les visiteurs de subir les conséquences, limiter la propagation du piratage, et préserver les preuves pour comprendre ce qui s’est passé.
Voici une courte séquence d’actions d’urgence, adaptée aux situations les plus fréquentes :
- Activer un mode maintenance ou couper temporairement l’accès public (via l’hébergeur, un plugin de maintenance ou une redirection simple). Sauvegarder une copie complète des fichiers et de la base de données, même si elle est infectée, pour analyse ultérieure. Noter l’heure de détection et les signes visibles (redirections, pop-ups, fichiers suspects) pour vous y retrouver plus tard. Vérifier les emails de l’hébergeur ou de services tiers pour repérer d’éventuels avertissements de sécurité. Changer immédiatement le mot de passe du compte d’hébergement principal, avant tout le reste.
Sauf cas particulier (site critique en production continue), il vaut mieux un site temporairement en maintenance qu’un site qui infecte les visiteurs ou envoie du spam pendant des heures.
Répertorier tous les accès sensibles avant de les changer
Avant de commencer à réinitialiser dans tous les sens, prenez dix minutes pour dresser une carte des accès liés à votre WordPress. C’est souvent ce moment de clarification qui évite d’en oublier un.
Deux catégories ressortent.
D’un côté, les accès “techniques” directement liés au site :
- Connexion au compte d’hébergement Panneau de contrôle (type cPanel, Plesk, interface propriétaire) FTP, SFTP ou SSH Base de données (MySQL, MariaDB, etc.) Compte(s) administrateur WordPress Accès au CDN ou au pare-feu applicatif (Cloudflare, Sucuri, etc.)
De l’autre, les accès “fonctionnels” souvent intégrés à WordPress :
- Compte du registrar (là où le nom de domaine est géré) Comptes d’email liés au domaine (webmail, Microsoft 365, Google Workspace, etc.) Comptes de services tiers connectés via plugins (paiement, emailing, SMS, CRM) Clés d’API stockées dans wp-config.php, dans la base de données ou dans l’interface d’un plugin
L’objectif est simple : lister tout ce qui mérite une réinitialisation, puis avancer méthodiquement. Quand on gère cette urgence pour des clients, on travaille toujours avec un tableau de suivi, même rudimentaire, pour cocher les accès réinitialisés. À chaud, la mémoire joue des tours.
L’accès à l’hébergement : la clé de voûte
Le compte d’hébergement, c’est la télécommande principale de votre site. S’il est compromis, tout le reste l’est potentiellement.
Dès que vous suspectez une intrusion, changez ce mot de passe, même si vous pensez que l’attaque vient d’un plugin ou d’une faille WordPress. Et ne vous contentez pas d’un nouveau mot de passe “un peu plus fort”. Optez pour un mot de passe long, unique, généré par un gestionnaire de mots de passe, et activez la double authentification si l’hébergeur la propose.
Dans certains cas, l’attaquant a aussi créé un sous-compte d’hébergement, par exemple un autre utilisateur pour le gestionnaire de fichiers ou un deuxième compte FTP. Il faut donc contrôler :
- Les utilisateurs ayant accès au panneau de contrôle Les rôles d’administration au niveau de l’hébergeur, s’il existe une gestion par équipe Les clés ou accès API de l’hébergeur (par exemple pour déployer automatiquement via un service externe)
Si vous trouvez des accès inconnus ou des autorisations anormalement larges, supprimez-les plutôt que de les modifier. Et notez dans un coin les éléments supprimés pour les recouper plus tard avec les logs.
FTP, SFTP et SSH : les portes directes au serveur
Dans beaucoup de piratages WordPress observés “in real life”, l’intrusion passe par un vieux compte FTP oublié, dont le mot de passe traîne depuis des années dans un client FTP mal protégé, un email ou un fichier texte.
Les accès FTP, SFTP et SSH doivent être repris de zéro :
- Supprimer les comptes inutiles ou inconnus Modifier les mots de passe de tous les comptes légitimes restants Désactiver complètement le FTP non sécurisé si possible, au profit de SFTP Limiter le plus possible les droits (par exemple, un compte qui ne voit qu’un dossier spécifique, pas tout l’hébergement)
Sur des environnements gérés, l’idéal est de ne garder qu’un seul accès SFTP/SSH nominal et d’utiliser les systèmes de déploiement (Git, outils de l’hébergeur) pour les modifications. Ce n’est pas toujours réaliste sur des petits hébergements mutualisés, mais c’est une direction à garder en tête après la crise.
Base de données : mots de passe et identifiants
L’attaquant qui obtient les identifiants de base de données peut :
- Lire / modifier les utilisateurs et leurs mots de passe (même hachés, ils peuvent être réutilisés si faibles ou connus) Insérer des contenus malveillants dans les articles, widgets, options, etc. Installer des comptes administrateur cachés dans la table des utilisateurs
Trois étapes sont essentielles.
D’abord, changer le mot de passe de la base de données depuis l’interface de l’hébergeur ou via le serveur de base. Ensuite, mettre à jour ce nouveau mot de passe dans le fichier wp-config.php. C’est ce fichier qui permet à WordPress de se connecter à la base. Si vous oubliez cette étape, le site affichera une erreur de connexion à la base.
Enfin, vérifier qu’un seul utilisateur de base de données est utilisé pour ce site, avec des droits aussi limités que possible. Sur certains hébergements mutualisés, plusieurs sites partagent la même base ou le même utilisateur. Dans un contexte de piratage, cette configuration multiplie les risques de contamination croisée. Si vous le pouvez, isolez ce site avec sa propre base et son propre utilisateur.
Comptes WordPress : ne garder que le nécessaire
Dans les sites que je récupère après un incident de sécurité, il y a régulièrement une surprise dans la liste des utilisateurs WordPress. Par exemple un compte admin nommé “support”, “test”, “temp” ou pire, un compte qui ressemble au vôtre avec une légère variation dans l’orthographe.
Le passage obligé consiste à faire un audit complet des utilisateurs :
- Supprimer tous les comptes administrateurs qui ne sont plus utilisés ou qui n’auraient jamais dû exister Passer les comptes trop puissants à un rôle plus limité (éditeur, auteur) lorsque c’est suffisant Forcer la réinitialisation des mots de passe pour tous les utilisateurs ayant un rôle élevé Vérifier les adresses email associées aux comptes admin, pour éviter un détournement via “mot de passe oublié”
Même si c’est un peu pénible, j’encourage souvent les clients à réinitialiser le mot de passe de tous les utilisateurs, pas seulement les administrateurs, lorsque des données d’authentification ont pu être compromises. Un utilisateur qui réutilise le même mot de passe ailleurs peut devenir une porte d’entrée indirecte.
Si votre site gère des comptes clients (WooCommerce, espace membre), l’envoi d’un message clair expliquant la situation de façon honnête et factuelle est préférable à un silence inquiétant. Vous n’avez pas besoin de tout détailler techniquement, mais de dire que des mesures de sécurité sont en cours et que la réinitialisation de mot de passe est préventive.
https://gardewp.fr/site-wordpress-pirate/wp-config.php, clés secrètes et paramètres sensibles
Le fichier wp-config.php est souvent oublié dans les réponses d’urgence, alors qu’il contient des informations critiques :
- Identifiants de base de données Préfixe des tables Clés de sécurité (AUTH KEY, SECUREAUTH_KEY, etc.) Parfois des clés API ou des options sur mesure
Si un attaquant a pu télécharger ce fichier, il connaît vos identifiants de base de données, mais aussi vos “salts” de sécurité. Ces chaînes servent à chiffrer et sécuriser les cookies de connexion. Tant qu’elles ne sont pas régénérées, des sessions déjà créées peuvent rester valides, même après un changement de mot de passe.
C’est un des points négligés qui expliquent les réinfections “magiques” alors que tout le monde jure avoir changé tous les mots de passe.
La démarche à suivre est la suivante : une fois le mot de passe de base de données modifié, utilisez le générateur officiel de clés et de salts WordPress, puis remplacez l’ensemble des constantes correspondantes dans wp-config.php. Cela déconnecte brutalement tous les utilisateurs, y compris un éventuel attaquant. Tout le monde devra se reconnecter avec un nouveau cookie généré sur cette base.
Profitez-en pour vérifier que le préfixe de table n’a pas été modifié de façon suspecte et qu’aucune constante étrange n’a été ajoutée. Des attaquants glissent parfois dans wp-config.php des includes discrets ou des variables destinées à charger du code malveillant très tôt dans le cycle de WordPress.
Emails, domaines et registrar : l’angle mort courant
Lors de certaines urgences WordPress piraté, l’accès le plus critique n’est pas celui auquel on pense. Par exemple, j’ai vu un cas où le pirate n’avait pas pris le contrôle direct du site, mais de la boîte mail du propriétaire. Avec cet accès, il a pu utiliser la fonction “mot de passe oublié” pour WordPress, l’hébergeur et même le registrar, puis changer progressivement tous les mots de passe.
Si votre adresse email principale est compromise, tout ce que vous réinitialisez peut être repris par l’attaquant via le lien envoyé par email. Il est donc vital de sécuriser aussi l’email.
Quelques points à vérifier avec attention :
- Les mots de passe de toutes les boîtes email liées au domaine Les redirections et transferts automatiques configurés dans le webmail Les règles de messagerie (parfois utilisées pour cacher des emails de notification) L’accès au compte du registrar, qui contrôle le nom de domaine lui-même
Si quelqu’un obtient l’accès au registrar, il peut modifier les DNS pour rediriger le trafic vers un serveur malveillant, ou voler le domaine. Dans ce cas, on dépasse largement le cadre WordPress. Activez la double authentification sur le registrar, vérifiez les contacts administratifs, et assurez-vous qu’aucun transfert de domaine n’est en cours sans votre accord.
API, plugins et services tiers : les accès cachés
WordPress ne vit pas seul. Sur un site de production, il s’intègre rarement avec moins de deux ou trois services tiers : outils de newsletter, gateway de paiement, CRM, analytics avancés, parfois stockage externe.
Ces services sont souvent connectés via des clés API ou des tokens stockés :
- Dans les réglages d’un plugin Dans la base de données, dans la table des options Parfois en clair dans wp-config.php ou dans d’autres fichiers de configuration
Un attaquant qui met la main sur ces informations n’est pas obligé de toucher au site pour faire des dégâts. Il peut par exemple :
- Envoyer des campagnes malveillantes via votre compte d’emailing Détourner des paiements via une mauvaise configuration de webhook Récupérer des données de clients ou de prospects stockées chez un tiers
La bonne pratique consiste à identifier pour chaque intégration :
Où se trouve la clé ou le token dans WordPress. Où se régénère cette clé dans l’interface du fournisseur (Mailchimp, Stripe, Sendinblue, etc.).Puis à régénérer les clés dans le service tiers, et à mettre à jour WordPress avec les nouvelles valeurs. Il ne suffit pas de “masquer” la clé dans WordPress, il faut l’invalider à la source.
Sur certains comptes Stripe piratés via un plugin WordPress, ce sont des webhooks mal contrôlés qui ont permis de rediriger une partie des flux ou d’obtenir des informations sensibles. Profitez de la crise pour faire un audit rapide de ces configurations.
Journaliser ce que vous faites, même dans l’urgence
En pleine urgence, prendre des notes semble être du luxe. Pourtant c’est souvent ce qui fera la différence entre un incident résolu en une fois et une série de réinfections sur plusieurs semaines.
Pour chaque accès réinitialisé, consignez la date, l’heure, l’ancien niveau de sécurité (si vous le connaissez) et le nouveau paramétrage. Cela vous servira à plusieurs choses :
- Vérifier que vous n’avez pas oublié un accès critique Aider un prestataire externe à comprendre ce qui a été fait si vous devez demander de l’aide Identifier rétrospectivement la phase d’attaque (si une nouvelle anomalie réapparaît après telle heure, c’est probablement autre chose)
Cette journalisation peut se faire dans un simple document texte, une feuille de calcul ou un outil de ticketing si vous en avez un. L’important n’est pas l’outil, c’est la discipline.
Nettoyer, puis seulement rouvrir le site
Réinitialiser tous les accès sensibles est une étape nécessaire, mais pas suffisante. Tant que les fichiers et la base de données contiennent du code malveillant, remettre le site en ligne est risqué, même avec de nouveaux mots de passe.
La séquence logique ressemble à ceci :
Contrôler que tous les accès principaux (hébergement, FTP/SFTP, base, utilisateurs WordPress, email, registrar, API clés) ont été repris en main. Utiliser un outil sérieux d’analyse de fichiers (Wordfence, ImunifyAV côté hébergeur, etc.) Pour détecter les scripts suspects. Comparer les fichiers de base de WordPress et des plugins avec des versions propres, idéalement en repartant d’installations neuves. Nettoyer la base de données, notamment les tables options, posts et users, pour traquer les injections courantes (iframes, scripts obfusqués, comptes cachés). Tester le site en mode restreint ou sur une copie de préproduction avant de réouvrir au public.Les accès réinitialisés réduisent fortement la probabilité d’un retour du pirate, mais une simple backdoor laissée dans un dossier uploads ou dans un thème enfant peut suffire à contourner tout ce que vous avez fait.
Penser à l’après-crise : transformer l’urgence en routine de sécurité
Une urgence WordPress piraté agit comme un crash test de votre organisation. Elle révèle les failles techniques, mais aussi les faiblesses de processus : mots de passe partagés dans l’équipe, absence de double authentification, manque de documentation sur les accès, dépendance à une seule personne “qui sait tout”.
Une fois la tempête passée, deux ou trois décisions structurantes peuvent changer durablement la donne.
D’abord, adopter un gestionnaire de mots de passe pour l’équipe, avec des coffres partagés et des accès nominaux. Cela évite les mots de passe envoyés par email, partagés sur des chat ou stockés en clair sur un ordinateur.
Ensuite, instaurer une politique de rotation minimale des mots de passe les plus sensibles, au moins pour l’hébergement, le registrar et les accès administrateurs. Il ne s’agit pas de les changer tous les mois, ce qui est contre-productif, mais de ne plus laisser vivre les mêmes identifiants pendant des années.
Enfin, configurer un minimum de surveillance : un système de notification en cas de modification de fichiers, des alertes de connexion suspecte, des journaux d’activité sur les actions d’administration. L’idée n’est pas de se transformer en SOC, mais de ne plus découvrir un piratage trois semaines après les premiers signes.
Quand faire appel à un spécialiste
Tout le monde n’a pas le temps, ni l’appétence technique, pour gérer une urgence complexe. Il y a des cas où appeler un spécialiste est rationnel :
- Site avec données personnelles sensibles, obligations RGPD fortes Plateforme e-commerce avec volumes de vente importants Suspicion forte que l’attaquant ait touché aussi les infrastructures annexes (emails, registrar, autres sites du même serveur) Manque de visibilité sur l’ampleur de la compromission
Même si vous travaillez avec un prestataire, comprendre l’importance de réinitialiser tous les accès sensibles vous permet de dialoguer à armes égales. Vous saurez poser les bonnes questions : “Avons-nous régénéré les clés de wp-config.php ?”, “Les accès FTP inactifs ont-ils été supprimés ?”, “Les clés API du plugin de paiement ont-elles été revues ?”.
L’objectif est simple : ne plus subir l’incident, mais en reprendre la maîtrise, étape par étape.
La sécurité WordPress n’est jamais parfaite, seulement relative. Toutefois, un site dont tous les accès sensibles ont été réinitialisés proprement après une intrusion, puis consolidés avec de bonnes pratiques, devient bien moins attrayant pour un attaquant automatisé. Et surtout, vous gagnez ce qui manque le plus en pleine urgence : la certitude raisonnable que vous êtes, à nouveau, le seul maître à bord.