Découvrir qu’un site WordPress a été compromis provoque toujours un moment de panique, souvent justifié par l’urgence réelle de la situation : redirection vers un site suspect, page d’accueil remplacée, alerte de Google Search Console signalant du contenu de spam, ou simplement un hébergeur qui suspend le compte pour activité malveillante détectée. Dans ces moments-là, agir vite est important, mais agir dans le bon ordre l’est tout autant.
Un nettoyage précipité, qui se contente de supprimer les fichiers visiblement suspects sans comprendre le point d’entrée initial, laisse souvent une porte dérobée en place, prête à être réutilisée dans les jours qui suivent. Voici la démarche complète, dans l’ordre, pour reprendre le contrôle d’un site compromis et éviter que l’incident ne se reproduise.
Isoler avant tout le reste
La première action, avant même de commencer à analyser quoi que ce soit, consiste à limiter la propagation et l’impact de la compromission. Mettre le site en mode maintenance ou le rendre temporairement inaccessible évite que du contenu malveillant continue à s’afficher pour les visiteurs, ce qui protège à la fois la réputation du site et ses utilisateurs.
- Mettre le site hors ligne ou en mode maintenance immédiatement
- Couper les accès FTP et les comptes utilisateurs suspects, sans encore rien supprimer
- Prévenir l’hébergeur, qui dispose parfois de journaux ou d’outils d’analyse complémentaires
Identifier le point d’entrée, pas seulement les symptômes
Supprimer un fichier malveillant sans comprendre comment il est arrivé là ne résout rien : si la porte d’entrée reste ouverte, un nouveau fichier réapparaîtra en quelques heures. Les points d’entrée les plus fréquents sont une extension ou un thème obsolète avec une vulnérabilité connue, un mot de passe faible ou réutilisé sur un compte administrateur, ou un accès FTP compromis par un poste infecté.
# Repérer les fichiers modifiés récemment dans wp-content
find wp-content -type f -mtime -30 -name "*.php"
# Comparer les extensions installées à leur version officielle
wp plugin list --format=json --fields=name,versionLes journaux d’accès du serveur, quand ils sont conservés sur une durée suffisante, permettent souvent de repérer la requête initiale de compromission : une tentative de connexion réussie après une série d’échecs, un accès direct à un fichier d’extension connu pour une faille, ou l’apparition d’un nouveau compte administrateur non créé par l’équipe.
Comparer avec une version saine connue
La méthode la plus fiable pour repérer les fichiers altérés consiste à comparer l’intégralité du cœur de WordPress, des thèmes et des extensions avec leurs versions officielles téléchargées depuis le dépôt WordPress.org, plutôt que de chercher à l’œil du code suspect dans des milliers de fichiers.
wp core verify-checksums
wp plugin verify-checksums --allCes commandes WP-CLI comparent les fichiers installés à leurs empreintes officielles et signalent toute différence, qu’il s’agisse d’un fichier modifié ou d’un fichier ajouté qui n’existe pas dans la distribution d’origine. Un fichier inconnu à la racine ou dans un dossier d’extension mérite toujours une inspection manuelle avant suppression, pour documenter ce qui a été trouvé.
Nettoyer, réinstaller, ne jamais faire confiance
Une fois le ou les points d’entrée identifiés, la reconstruction est plus sûre qu’un nettoyage chirurgical incertain. Réinstaller le cœur de WordPress, les thèmes et les extensions depuis des sources officielles, plutôt que de tenter de corriger fichier par fichier, élimine le doute sur d’éventuelles modifications non détectées.
- Restaurer la base de données depuis la dernière sauvegarde saine connue, antérieure à la compromission
- Réinstaller intégralement le cœur, les thèmes et les extensions depuis des sources officielles
- Vérifier manuellement le dossier
wp-content/uploads, souvent négligé car considéré à tort comme non exécutable - Rechercher des comptes administrateur créés récemment et non reconnus par l’équipe
Changer tous les secrets, sans exception
Une compromission, même partiellement comprise, doit toujours déclencher un renouvellement complet des secrets : mots de passe de tous les comptes WordPress, mot de passe de la base de données, identifiants FTP et SSH, et clés AUTH_KEY et SALT dans wp-config.php, qui invalident au passage toutes les sessions actives, y compris celle d’un attaquant encore connecté.
| Secret | Action |
|---|---|
| Mots de passe utilisateurs | Réinitialisation forcée pour tous les comptes |
| Clés AUTH_KEY / SALT | Régénération complète, invalide les sessions actives |
| Identifiants FTP / SSH / base de données | Changement systématique, même sans certitude de fuite |
Prévenir la récidive
Un site nettoyé sans correction de la cause initiale reste exposé au même scénario. Après restauration, une revue complète des extensions actives, de leur nécessité réelle et de leur maintenance à jour, combinée à la mise en place d’une veille vulnérabilités et d’une politique de mots de passe robuste avec authentification à deux facteurs sur les comptes administrateur, réduit fortement le risque de répétition.
Après chaque incident que j’ai traité, je documente une chronologie complète : ce qui a été trouvé, quand, et ce qui a été changé. Ce document sert autant à rassurer le client qu’à éviter de refaire la même erreur six mois plus tard.
En résumé
Nettoyer un site WordPress piraté demande de la méthode plus que de la vitesse : isoler d’abord, comprendre le point d’entrée ensuite, reconstruire depuis des sources fiables plutôt que rafistoler, et changer systématiquement tous les secrets sans exception. C’est ce cheminement rigoureux, documenté à chaque étape, qui transforme un incident subi en une occasion de repartir sur des bases réellement plus sûres.
