Que faire si votre site WordPress est piraté ?

Un site WordPress piraté ne doit pas être traité comme un simple bug d’affichage. Une redirection inconnue, des comptes administrateurs ajoutés, des fichiers modifiés ou des alertes de navigateur peuvent signaler une compromission active. La priorité est de contenir l’incident, de préserver les éléments utiles au diagnostic, puis de rétablir une version saine sans réintroduire la faille. Ce guide explique comment réparer un site WordPress piraté, qu’il s’agisse d’un site vitrine ou d’une boutique, sans confondre remise en ligne et suppression de la cause de l’intrusion.

Si vous avez besoin d’une prise en charge, notre accompagnement en sécurité WordPress couvre l’analyse de la compromission et les mesures de protection. Pour une panne sans signe d’intrusion, consultez plutôt le service de dépannage WordPress.

1. Confirmer l’incident et limiter immédiatement les dégâts

Commencez par vérifier les symptômes depuis plusieurs contextes : navigation privée, autre réseau, smartphone et outil d’inspection du navigateur. Certaines infections ne ciblent que les visiteurs provenant des moteurs de recherche ou les utilisateurs non connectés. Consultez également Google Search Console : les rapports « Problèmes de sécurité » et « Actions manuelles » peuvent signaler du contenu piraté ou des redirections trompeuses.

Si la compromission est plausible, réduisez l’exposition avant de nettoyer :

• activez une page de maintenance au niveau de l’hébergement ou bloquez temporairement l’accès public par mot de passe ;
• prévenez les personnes qui administrent le site de ne plus se connecter avec leurs identifiants habituels ;
• ne supprimez pas immédiatement les fichiers suspects : ils peuvent aider à comprendre le point d’entrée ;
• désactivez les campagnes publicitaires, formulaires sensibles et paiements si le site traite des données ou des commandes.

Une simple extension de maintenance ne suffit pas toujours : elle charge encore WordPress et ses extensions. En cas de code malveillant actif, une protection côté serveur, un mot de passe HTTP ou une règle temporaire dans le panneau d’hébergement est plus fiable.

2. Sauvegarder l’état compromis avant toute modification

Créez une copie complète des fichiers et une exportation de la base de données, avec une date explicite, par exemple incident-2026-10-01. Cette sauvegarde ne doit pas servir à restaurer le site tel quel ; elle sert à comparer, rechercher une date d’intrusion et conserver une trace si nécessaire.

Notre guide des sauvegardes WordPress détaille les contrôles d’une copie exploitable. Depuis SSH, un technicien peut archiver les fichiers et exporter la base. Exécutez ces commandes depuis un répertoire privé, hors de la racine web, et adaptez les chemins et identifiants à votre hébergement :

tar -czf incident-fichiers.tar.gz public_html/
mysqldump -u utilisateur_db -p nom_base > incident-base.sql

Dans le tableau de bord de l’hébergeur, téléchargez aussi les journaux d’accès et d’erreurs disponibles. Recherchez notamment des requêtes POST répétées vers wp-login.php, xmlrpc.php, admin-ajax.php ou un fichier PHP inhabituel dans wp-content/uploads/. Les logs ne prouvent pas seuls l’origine de l’attaque, mais ils peuvent révéler une adresse IP, une période ou un script ciblé.

3. Identifier le périmètre de la compromission

Avant de restaurer, contrôlez ce qui a été touché. Dans WordPress, examinez la liste des utilisateurs et recherchez les rôles administrateur inattendus. Vérifiez aussi les extensions, les thèmes, les réglages généraux, l’adresse e-mail d’administration et les clés d’API ou de paiement.

Fichiers à examiner en priorité

• wp-config.php, .htaccess, index.php à la racine et les fichiers PHP récemment modifiés ;
• les répertoires wp-content/mu-plugins/, wp-content/uploads/ et wp-content/cache/ ;
• les fichiers PHP au nom trompeur ou aléatoire, par exemple class-xyz.php, surtout dans les dossiers normalement dédiés aux médias ;
• les tâches planifiées WordPress et serveur, à examiner avec l’hébergeur ou sur une copie isolée ; ne lancez pas du code provenant de l’installation compromise sans environnement adapté.

Des fonctions comme base64_decode(), eval(), gzinflate() ou str_rot13() méritent une vérification lorsqu’elles sont combinées à du code obfusqué. Elles ne constituent pas, isolément, une preuve d’infection : des extensions légitimes peuvent les employer. Comparez toujours avec la version officielle du thème ou de l’extension concernée.

Contrôler la base de données

Dans phpMyAdmin ou avec un outil SQL, examinez les tables de contenu, d’options et d’utilisateurs. Recherchez des balises <script>, des iframes inconnues, des liens injectés, ou des valeurs suspectes dans les options chargées automatiquement. La table porte souvent le préfixe wp_, mais ce préfixe peut être personnalisé. Les redirections malveillantes sont fréquemment cachées dans un widget, un constructeur de pages, un champ d’en-tête/pied de page ou une option de thème.

4. Restaurer proprement plutôt que réparer à l’aveugle

La méthode la plus fiable consiste à repartir d’une sauvegarde antérieure à l’intrusion, à condition qu’elle soit identifiée, complète et conservée hors du serveur. Restaurez-la idéalement sur un environnement de préproduction ou un sous-domaine protégé afin de la contrôler avant remise en ligne.

Si aucune sauvegarde saine n’existe, remplacez les composants WordPress par des sources officielles :

1. téléchargez la même version de WordPress depuis wordpress.org, ou la version actuelle compatible après vérification ;
2. remplacez les dossiers wp-admin et wp-includes en entier ;
3. remplacez chaque extension et chaque thème par une archive officielle ou une copie fiable provenant de son éditeur ;
4. récupérez les médias, configurations et développements personnalisés uniquement après contrôle ; examinez notamment wp-content/uploads, les extensions indispensables et wp-config.php, sans supprimer aveuglément les données métier ;
5. supprimez les extensions et thèmes inutilisés, y compris les thèmes inactifs non nécessaires.

Ne copiez pas un dossier wp-content compromis par-dessus une installation neuve sans tri : cela réintroduit facilement un backdoor. Pour les médias, n’autorisez normalement que les fichiers attendus (images, PDF, vidéos selon votre usage). Un fichier .php dans uploads est à traiter comme suspect jusqu’à justification.

5. Réinitialiser tous les accès et secrets

Changer uniquement le mot de passe WordPress est insuffisant. Renouvelez les accès qui auraient pu être lus dans les fichiers ou utilisés par l’attaquant :

• mots de passe des comptes WordPress, en supprimant les utilisateurs inconnus ;
• compte d’hébergement, SFTP/SSH, base de données et adresse e-mail administrateur ;
• clés API, jetons SMTP, clés de paiement, accès CDN et identifiants de sauvegarde ;
• salts WordPress dans wp-config.php, générés depuis l’API officielle de clés secrètes WordPress.

Après modification des salts, toutes les sessions WordPress existantes sont invalidées. Activez l’authentification à deux facteurs pour les administrateurs lorsque votre solution de gestion des comptes le permet. Appliquez le principe du moindre privilège : un rédacteur n’a pas besoin du rôle administrateur.

6. Corriger la cause d’entrée et renforcer l’installation

Un nettoyage sans correction de la faille conduit souvent à une nouvelle infection. Mettez à jour le cœur WordPress, les extensions et les thèmes après avoir validé leur compatibilité sur une copie du site. Supprimez tout composant abandonné, nulled ou téléchargé hors du canal de l’éditeur. Vérifiez que PHP est encore maintenu par votre hébergeur et que les droits de fichiers ne sont pas inutilement permissifs : en règle générale, 644 pour les fichiers et 755 pour les dossiers conviennent sur de nombreux hébergements, sous réserve de leur configuration.

Installez une sauvegarde automatisée avec rétention et stockage externe. Testez réellement une restauration : une sauvegarde non restaurable n’est pas un plan de reprise. Limitez les tentatives de connexion, protégez l’accès administrateur, désactivez les comptes non utilisés et mettez en place un suivi des changements. Si XML-RPC n’est pas requis par vos outils, restreignez-le au niveau du pare-feu applicatif ou serveur plutôt que de supprimer des fichiers du cœur.

7. Vérifier avant et après la remise en ligne

Testez aussi les parcours avec un compte utilisateur ordinaire. Une page d’accueil fonctionnelle ne suffit pas à valider les formulaires, les comptes et les fonctions commerciales.

Avant d’ouvrir de nouveau le site, testez les pages principales, la connexion, les formulaires, la recherche, les e-mails transactionnels et le tunnel de commande s’il existe. Contrôlez le code source généré sur plusieurs pages et les réponses HTTP pour repérer une redirection non voulue. Lancez un scan de sécurité comme contrôle complémentaire, sans considérer son résultat comme une garantie absolue.

Après la remise en ligne, surveillez les nouveaux fichiers, les comptes créés, les erreurs serveur et les alertes Search Console. Si Google avait signalé un problème de sécurité, demandez un examen après nettoyage. Documentez enfin la chronologie, les fichiers supprimés, les accès renouvelés et la faille corrigée : ce journal rend la maintenance du site WordPress plus rapide et plus sûre lors d’un futur incident.