Une redirection vers un site de jeux, un avertissement rouge dans Chrome, un administrateur que personne ne connaît : ces signaux ne prouvent pas tous un piratage, et un site compromis peut aussi paraître parfaitement normal. Cet article vous donne une méthode pour trancher en moins d’une heure : les signes qui doivent alerter, les contrôles externes et internes à faire dans l’ordre, les commandes WP-CLI de vérification d’intégrité et la lecture des journaux.
Les signes qui doivent vous alerter
La documentation officielle de WordPress parle d’indicateurs de compromission. Certains sont visibles par tous, d’autres seulement par des outils ou par certains visiteurs. Le tableau suivant les classe selon l’endroit où les vérifier.
| Signe | Ce que vous constatez | Où vérifier en premier | Niveau d’alerte |
|---|---|---|---|
| Avertissement de navigation | Page rouge « site dangereux » dans le navigateur ou mention dans les résultats | Search Console, rapport « Problèmes de sécurité » | Élevé |
| Pages de spam indexées | Titres en japonais, pharmacie, contrefaçon dans les résultats Google | Recherche site:votredomaine.fr | Élevé |
| Redirections | Les visiteurs venant de Google ou d’un mobile partent vers un autre site | Test curl avec Referer et User-Agent | Élevé |
| Comptes inconnus | Administrateur créé récemment, adresse de récupération modifiée | wp user list --role=administrator | Élevé |
| Site suspendu | L’hébergeur a désactivé le site ou signale des envois de spam | Courriel ou support de l’hébergeur | Élevé |
| Fichiers modifiés | Fichiers du cœur différents de l’original, PHP dans uploads | Sommes de contrôle WP-CLI, scanner | Moyen à élevé |
| Lenteurs, pics de trafic | Charge serveur anormale, requêtes POST vers des fichiers inconnus | Journaux d’accès | À confirmer |
Un signe isolé de la dernière ligne ne suffit pas : une lenteur peut venir d’une extension mal codée ou d’une vague de robots. À l’inverse, un compte administrateur inconnu ou un fichier PHP dans le dossier des médias justifient de passer immédiatement en mode « incident ».
Pourquoi vous ne voyez rien alors que Google voit quelque chose
Beaucoup de logiciels malveillants pratiquent le camouflage (cloaking) : ils ne montrent la redirection ou le contenu de spam qu’à certains visiteurs. Les critères habituels sont l’absence de cookie de connexion, la provenance depuis un moteur de recherche (en-tête Referer), le type d’appareil ou le robot d’indexation (en-tête User-Agent). Connecté à votre Tableau de bord, vous voyez donc souvent un site propre.
Google recommande de ne pas ouvrir directement dans un navigateur les pages signalées comme infectées, et de passer plutôt par l’outil d’inspection d’URL de la Search Console ou par curl, en faisant varier le Referer et le User-Agent :
# Comme un visiteur arrivant depuis Google
curl -s -e "https://www.google.com/" -A "Mozilla/5.0 (Linux; Android 14) Mobile" https://votredomaine.fr/ | head -50
# Comme le robot de Google
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://votredomaine.fr/ | head -50
# Seulement les en-têtes : une redirection 301/302 inattendue se voit tout de suite
curl -sI -e "https://www.google.com/" https://votredomaine.fr/Comparez les réponses avec celle d’une requête sans option. Un bloc de liens, un script inconnu ou un en-tête Location vers un autre domaine dans une seule des variantes est un signe fort.
Les contrôles externes, en dix minutes
- Search Console, rapport « Problèmes de sécurité » : Google y classe les alertes en contenu piraté (injection de code, de contenu ou d’URL), logiciels malveillants et ingénierie sociale, avec des exemples d’URL.
- Search Console, propriétaires et utilisateurs : un propriétaire que vous ne connaissez pas est, selon Google, un signe fort de compromission. Les pirates l’ajoutent pour faire indexer leurs pages et soumettre leurs propres plans de site.
- Recherche
site:votredomaine.fr: parcourez plusieurs pages de résultats à la recherche d’URL ou de titres qui ne viennent pas de vous. - État Safe Browsing : le rapport de transparence de Google indique si votre domaine est actuellement signalé comme dangereux.
- Analyseurs à distance : Sucuri SiteCheck et VirusTotal examinent ce qui est publiquement accessible. Sucuri précise lui-même que SiteCheck ne détecte rien côté serveur.
Ces contrôles ne demandent aucun accès au serveur : vous pouvez les faire même si vous ne gérez pas l’hébergement. Ils ne prouvent pas l’absence de piratage, car une porte dérobée silencieuse ne laisse aucune trace visible de l’extérieur.
Vérifier l’intégrité des fichiers avec WP-CLI
WP-CLI télécharge les sommes de contrôle publiées par WordPress.org et les compare à vos fichiers. C’est le contrôle le plus fiable pour le cœur et les extensions gratuites, et il ne charge pas WordPress, ce qui évite d’exécuter un code malveillant pendant la vérification.
# Cœur de WordPress, avec signalement des fichiers inconnus à la racine
wp core verify-checksums --include-root
# Toutes les extensions issues de wordpress.org
wp plugin verify-checksums --all
# Fichiers PHP présents dans les médias (il ne devrait y en avoir aucun)
find wp-content/uploads -type f -name "*.php"
# Fichiers PHP modifiés ces 7 derniers jours
find . -type f -name "*.php" -mtime -7Lisez bien les limites de ces commandes :
wp core verify-checksumssignale les fichiers du cœur modifiés. Sans--include-root, un fichier ajouté à la racine (par exemple un fauxwp-user.php) passe inaperçu.wp plugin verify-checksumsne compare que les extensions publiées sur wordpress.org. Les extensions premium doivent être comparées avec une archive téléchargée chez l’éditeur.- WP-CLI ne propose pas de commande équivalente pour les thèmes : le fichier
functions.phpdu thème actif est pourtant une cachette fréquente. - La date de modification d’un fichier se falsifie facilement : un fichier ancien en apparence n’est pas forcément sain.
Comptes, extensions cachées et tâches planifiées
Les pirates cherchent à garder un accès même après un nettoyage partiel. Les cas publiés par Sucuri en 2025 montrent les techniques courantes : en juillet, une porte dérobée placée dans wp-content/mu-plugins/wp-index.php créait un administrateur caché nommé « officialwp » ; en septembre, une fausse extension « DebugMaster » se retirait de la liste des extensions et filtrait la liste des utilisateurs, tandis qu’un fichier wp-user.php à la racine recréait le compte « help » s’il était supprimé.
Comme ces comptes peuvent être masqués dans le Tableau de bord, interrogez directement la base :
# Administrateurs, avec date d’inscription
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Extensions « must-use » et drop-ins, absentes de la liste habituelle
wp plugin list --status=must-use
wp plugin list --status=dropin
# Tâches planifiées : un hook au nom inconnu mérite une recherche
wp cron event list- Les extensions du dossier
mu-pluginsse chargent automatiquement, ne peuvent pas être désactivées depuis l’administration et n’apparaissent que dans l’onglet « Indispensables ». - Un administrateur créé à une date où personne n’a travaillé sur le site, ou avec une adresse e-mail jetable, doit être considéré comme hostile.
- Contrôlez aussi les accès hors WordPress : comptes FTP ou SFTP, clés SSH, utilisateurs de la base de données, comptes du panneau de l’hébergeur.
Lire les journaux du serveur
Les journaux d’accès (access log) répondent à deux questions : depuis quand, et par où. Leur emplacement dépend de l’hébergement : rubrique dédiée du panneau sur un mutualisé, souvent /var/log/apache2/ ou /var/log/nginx/ sur un serveur que vous administrez. Le fichier wp-content/debug.log n’existe que si la journalisation de débogage est activée, et il ne doit jamais rester public.
# Requêtes POST vers des fichiers PHP autres que les points d’entrée habituels
grep "POST " access.log | grep -v -E "wp-login.php|admin-ajax.php|wp-cron.php|xmlrpc.php" | grep "\.php"
# Tout accès à un fichier PHP du dossier des médias
grep -E "/wp-content/uploads/.*\.php" access.log
# Adresses IP les plus actives sur la page de connexion
grep "wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | headUne requête POST répétée vers un fichier au nom anodin (par exemple dans un dossier de thème) et répondant 200 est typique d’une porte dérobée. Notez l’heure de la première occurrence : elle sert à choisir une sauvegarde antérieure à l’intrusion. Les journaux sont souvent conservés peu de temps, copiez-les avant toute autre action.
Quel outil pour quel contrôle
| Outil | Type | Ce qu’il voit | Ce qu’il ne voit pas |
|---|---|---|---|
| Search Console | Externe, Google | Alertes de sécurité, pages indexées, propriétaires ajoutés | Portes dérobées sans effet visible |
| Sucuri SiteCheck, VirusTotal | Analyse à distance | Code malveillant dans les pages publiques, listes noires | Fichiers sur le serveur, base de données |
| WP-CLI (sommes de contrôle) | Sur le serveur | Cœur et extensions wordpress.org modifiés, fichiers en trop à la racine | Thèmes, extensions premium, uploads, base |
| Wordfence (scanner) | Extension | Signatures de logiciels malveillants, comparaison avec wordpress.org | Comparaison des thèmes et extensions désactivée dans le scan standard ; signatures gratuites décalées de 30 jours |
| Journaux d’accès | Serveur | Chronologie, fichiers appelés, adresses IP | Contenu des fichiers |
Aucun outil ne couvre tout. Combinez au moins un contrôle externe, une vérification d’intégrité côté serveur et une revue des comptes. En cas de piratage confirmé, la suite se joue dans la procédure de nettoyage pas à pas. Pour l’analyse côté serveur, notre comparatif des meilleurs plugins de sécurité WordPress indique lesquels intègrent un scanner de logiciels malveillants.
Détecter plus tôt la prochaine fois
Le meilleur diagnostic est celui que vous n’avez pas à lancer à la main. WP Masquerade Pro intègre un contrôle d’intégrité du cœur de WordPress et des alertes par e-mail avec un rapport hebdomadaire. La version gratuite compte déjà, avec les pièges à robots, les robots qui cherchent des failles ou des fichiers sensibles. Ce n’est ni un antivirus ni un outil de désinfection : il complète un scanner et vos sauvegardes, il ne les remplace pas.
Pour confirmer un soupçon infection par infection, avec les commandes et requêtes SQL correspondantes, voyez comment détecter si un site WordPress est piraté.
À lire aussi : Site WordPress piraté : comment réagir et le réparer.
À retenir
- Un site qui semble normal une fois connecté peut être infecté : testez en navigation privée et avec
curlen imitant Google. - Commencez par la Search Console (problèmes de sécurité et propriétaires), puis vérifiez les fichiers avec
wp core verify-checksums --include-rootetwp plugin verify-checksums --all. - Contrôlez ce que les sommes de contrôle ne voient pas : thème,
mu-plugins,uploads, extensions premium, base de données. - Listez les administrateurs en ligne de commande, car ils peuvent être masqués dans le Tableau de bord.
- Copiez les journaux tout de suite : ils datent l’intrusion et orientent le nettoyage.
Sources
- WordPress.org : FAQ My site was hacked (nouvel onglet)
- WP-CLI : wp core verify-checksums (nouvel onglet)
- WP-CLI : wp plugin verify-checksums (nouvel onglet)
- Google : rapport sur les problèmes de sécurité (Search Console) (nouvel onglet)
Autres sources consultées : documentation officielle, pages officielles des éditeurs, publications de chercheurs en sécurité et base Wordfence.
