Site WordPress piraté : que faire, dans quel ordre

Des visiteurs redirigés vers un site de pharmacie, des milliers de pages en japonais sous votre domaine dans Google, un administrateur que personne ne connaît : le site est piraté. Le réflexe est de tout effacer au plus vite. C'est souvent ce qui fait perdre le plus de temps ensuite. Ce guide donne l'ordre dans lequel je procède, et pourquoi.

1. Confirmer, sans se fier à ce qu'on voit connecté

Beaucoup d'infections se cachent de l'administrateur : la redirection ne se déclenche que pour un visiteur venu de Google, sur mobile, ou non connecté. Le site paraît normal depuis votre navigateur habituel alors que vos visiteurs, eux, partent ailleurs.

• Ouvrez le site en navigation privée, depuis un téléphone, et depuis un résultat de recherche Google.
• Cherchez site:votre-domaine.fr dans Google : des titres en langue étrangère ou des pages que vous n'avez jamais créées signent une injection de spam.
• Ouvrez le rapport Problèmes de sécurité de la Search Console, et vérifiez la liste des propriétaires : un attaquant s'ajoute parfois comme propriétaire validé pour soumettre ses propres sitemaps.

2. Garder les traces avant de toucher à quoi que ce soit

Copiez l'état compromis : les fichiers du site, un export de la base de données, et surtout les journaux d'accès du serveur web. Ce sont les seules traces de l'intrusion. Sans elles, trouver la porte d'entrée devient une devinette.

Si le site redirige des visiteurs ou distribue un logiciel malveillant, mettez-le hors ligne ou derrière une page de maintenance le temps du nettoyage. Un site coupé une journée coûte moins cher qu'une liste noire qui dure.

3. Couper les accès de l'attaquant

• Listez les comptes administrateurs et supprimez ceux que vous ne connaissez pas : wp user list --role=administrator.
• Changez les mots de passe de l'hébergement, du SFTP, de la base de données et des comptes WordPress.
• Renouvelez les clés de sécurité (AUTH_KEY et suivantes) dans wp-config.php : toutes les sessions ouvertes, y compris celles de l'attaquant, sont déconnectées. wp config shuffle-salts le fait en une commande.

Ces changements seront à refaire après le nettoyage : tant qu'une porte dérobée reste en place, l'attaquant peut relire les nouveaux mots de passe.

4. Trouver ce qui a été modifié

Les fichiers

WP-CLI compare les fichiers du cœur et des extensions avec les originaux publiés sur WordPress.org :

wp core verify-checksums
wp plugin verify-checksums --all

Tout fichier modifié ou ajouté est suspect. La vérification des extensions ne couvre que celles distribuées par WordPress.org : les extensions premium et les thèmes se comparent à une archive téléchargée chez l'éditeur.

Cherchez ensuite là où WordPress ne dépose jamais de code :

# Du PHP dans les médias envoyés : jamais légitime
find wp-content/uploads -name "*.php"

# Extensions chargées sans activation, souvent oubliées
ls -la wp-content/mu-plugins

# Fonctions typiques du code obfusqué
grep -rlE "eval\(base64_decode|gzinflate\(|str_rot13\(" wp-content

Ces motifs existent aussi dans du code légitime : chaque résultat se lit avant d'être supprimé. Méfiez-vous des dates de modification : un attaquant peut les falsifier pour faire passer un fichier ajouté pour un fichier d'origine. Relisez enfin wp-config.php, .htaccess et index.php à la racine, souvent retouchés pour charger le code malveillant à chaque requête.

La base de données

• Les options siteurl et home, détournées pour une redirection globale.
• Le contenu des articles et des widgets : des balises <script> ou des iframe que vous n'avez pas écrites.
• Les tâches planifiées (wp cron event list) : une tâche inconnue peut réinstaller le code supprimé.
• Les droits des utilisateurs dans wp_usermeta, pour un compte d'apparence anodine promu administrateur.

5. Trouver la porte d'entrée

C'est l'étape qu'on saute le plus souvent, et la raison principale des réinfections. Les causes habituelles :

• Une extension ou un thème vulnérable, pas mis à jour. Comparez vos versions installées aux bases publiques de vulnérabilités WordPress.
• Une extension « nulled », version piratée d'une extension payante : le code malveillant est livré avec.
• Un mot de passe réutilisé ou deviné, sur un compte WordPress, SFTP ou le panneau de l'hébergeur.
• Un autre site du même hébergement, compromis, qui écrit dans les dossiers voisins.

Une extension à jour n'est pas une garantie. En septembre 2020, File Manager, installée sur environ 700 000 sites, a été attaquée avant même la publication de son correctif (CVE-2020-25213) : n'importe qui pouvait déposer et exécuter un fichier PHP. En novembre 2018, une faille de WP GDPR Compliance (CVE-2018-19207), exploitée elle aussi, permettait de modifier les réglages du site, par exemple pour ouvrir les inscriptions avec le rôle administrateur. Dans les deux cas, la mise à jour fermait la porte mais ne retirait ni les fichiers déposés ni les comptes créés entre-temps.

Les journaux d'accès recoupent ces hypothèses : cherchez les requêtes POST vers les fichiers suspects trouvés à l'étape 4, et remontez à la première. Sa date et l'URL appelée juste avant désignent souvent la faille.

6. Nettoyer par remplacement

Corriger les fichiers un par un laisse presque toujours quelque chose. Je remplace plutôt tout ce qui peut l'être :

• le cœur, depuis l'archive officielle : wp core download --force --skip-content ;
• les extensions et les thèmes, réinstallés depuis WordPress.org ou chez l'éditeur, dans leur dernière version ;
• les extensions inutilisées et les copies « nulled », supprimées ;
• les médias conservés, mais débarrassés de tout fichier PHP.

Ce qui ne se remplace pas, comme un thème développé sur mesure, se compare à la version du dépôt git s'il en existe une, ou se relit entièrement.

Empêchez ensuite l'exécution de PHP dans les médias. Avec Nginx :

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

Avec Apache, un fichier .htaccess dans wp-content/uploads :

<Files "*.php">
    Require all denied
</Files>

7. Refermer et durcir

• Refaites le changement de tous les accès et des clés de sécurité, maintenant que le site est propre.
• Mettez à jour ce qui reste, et corrigez la cause trouvée à l'étape 5.
• Désactivez l'éditeur de fichiers de l'administration : define('DISALLOW_FILE_EDIT', true);.
• Activez la double authentification pour les administrateurs.

Le guide sécuriser WordPress en production détaille ces réglages, et la routine de maintenance explique comment tenir les mises à jour et les sauvegardes dans la durée.

8. Rétablir la situation dans Google

• Retirez les propriétaires inconnus de la Search Console et les sitemaps qu'ils ont soumis.
• Vérifiez que les pages de spam supprimées renvoient bien une erreur 404 ou 410, pas une redirection vers l'accueil.
• Pour les URL les plus visibles, l'outil de suppression de la Search Console les masque temporairement le temps que Google les réexplore.
• Si le site est signalé, demandez un réexamen depuis le rapport Problèmes de sécurité, en décrivant ce qui a été nettoyé et corrigé.

Surveillez ensuite le rapport d'indexation : le nombre de pages indexées doit redescendre vers celui de vos pages réelles au fil des semaines.

En résumé

Si vous préférez confier le travail, je m'en occupe au forfait : voir nettoyage d'un site WordPress piraté.