Trois choses avant tout le reste

1. Sauvegardez le site infecté — fichiers et base. C'est votre preuve et votre filet de sécurité.
2. Ne supprimez rien tout de suite. Effacer le code malveillant détruit la piste qui mène à la porte dérobée.
3. Si le site encaisse des paiements, passez-le en maintenance maintenant. Une page de paiement compromise capture des numéros de carte.

Étape 1 : mesurer l'étendue

Avant de nettoyer, déterminez jusqu'où ça va. En mutualisé, un site infecté contamine régulièrement tous les autres sites du même compte : vous nettoyez l'un, le voisin le réinfecte dans l'heure.

  • D'autres sites sur ce compte ? Vérifiez-les tous.
  • Le compte d'hébergement lui-même est-il compromis ? Cherchez des utilisateurs SFTP et des clés SSH que vous n'avez pas créés.
  • Des administrateurs inconnus ? Regardez dans Comptes, mais aussi directement en base : certains codes malveillants masquent les comptes dans l'interface.
  • Que voit Google ? Cherchez site:votredomaine.fr et repérez les pages que vous n'avez jamais écrites. Consultez le rapport « Problèmes de sécurité » de la Search Console.

Étape 2 : identifier le point d'entrée

C'est l'étape que tout le monde saute, et c'est la raison des échecs. Vous cherchez la réponse à une seule question : par où sont-ils entrés ?

Lire les dates de modification

Des fichiers modifiés à 3 h du matin un jour où vous n'avez rien déployé, voilà votre carte. En SSH :

# Fichiers PHP modifiés ces 14 derniers jours
find . -name "*.php" -mtime -14 -ls

# Fichiers PHP cachés dans les médias — presque toujours malveillants
find wp-content/uploads -name "*.php"

Il n'existe pratiquement aucune raison légitime pour qu'un fichier PHP se trouve dans wp-content/uploads/. Si vous en trouvez un, vous avez trouvé un shell.

Lire les journaux d'accès

Les journaux de votre hébergeur montrent les requêtes qui précèdent le premier fichier modifié. Cherchez les requêtes POST vers des chemins inhabituels, les appels répétés vers un point d'entrée d'extension, et l'adresse IP qui revient. Cela désigne généralement l'extension vulnérable.

Comparer les versions d'extensions

Recoupez chaque extension installée et sa version avec la base de vulnérabilités WPScan. Une extension obsolète avec une faille d'exécution de code à distance publiée est le suspect numéro un.

Étape 3 : remplacer plutôt que désinfecter

  1. Le cœur de WordPress. Supprimez wp-admin/ et wp-includes/ et remettez des copies neuves de la même version.
  2. Extensions et thèmes. Supprimez tout, réinstallez depuis le dépôt officiel ou votre éditeur. Une extension abandonnée ne revient pas.
  3. Les fichiers racine. Comparez index.php, wp-config.php et .htaccess à des références saines. Le code malveillant adore les règles de redirection.
  4. wp-content/uploads. Gardez vos médias, supprimez tout fichier exécutable. Des images, rien d'autre.

Étape 4 : nettoyer la base de données

  • Scripts injectés dans les contenus — cherchez <script, eval( et des iframes dans wp_posts.
  • Entrées parasites dans wp_options — surtout celles en autoload, exécutées à chaque chargement.
  • Administrateurs non autorisés dans wp_users et wp_usermeta.
  • Tâches planifiées malveillantes dans l'option cron — un grand classique pour retélécharger la charge après votre nettoyage.

Étape 5 : renouveler tous les identifiants

Considérez comme compromis tout ce que le site pouvait atteindre :

  • Mot de passe de la base (à répercuter dans wp-config.php)
  • Panneau d'hébergement, SFTP et SSH — supprimez les clés inconnues
  • Chaque mot de passe administrateur
  • Les clés de sécurité de wp-config.php — régénérez-les : cela déconnecte toutes les sessions, y compris celle de l'attaquant
  • Toute clé d'API stockée : paiement, SMTP, intégrations tierces

Étape 6 : sortir de la liste noire

Uniquement une fois le site vérifié sain. Une demande de réexamen refusée ralentit la suivante : vérifiez d'abord avec un scan indépendant, puis, dans la Search Console, ouvrez Sécurité et actions manuelles → Problèmes de sécurité et demandez un réexamen. Comptez quelques jours.

Le piège de la réinfection

Si votre site a déjà été nettoyé puis réinfecté, c'est que le nettoyage précédent a retiré la charge utile en laissant la porte ouverte. Les portes dérobées se cachent dans des fichiers parfaitement ordinaires : quelques octets ajoutés à un fichier de thème légitime, un faux wp-cache.php à la racine, un mu-plugin discret. Nommer le point d'entrée est le seul moyen de savoir que c'est terminé.

Le faire proprement, une seule fois ?

Nettoyage complet : point d'entrée identifié, portes dérobées supprimées, identifiants renouvelés, durcissement, et rapport écrit expliquant par où ils sont passés.

Questions fréquentes

Comment mon site a-t-il été piraté ?

La grande majorité des compromissions passent par une extension obsolète avec une faille connue. Ensuite viennent les mots de passe faibles ou réutilisés, un compte d'hébergement compromis, ou la contamination par un autre site du même serveur.

Pourquoi suis-je réinfecté après un nettoyage ?

Le nettoyage a supprimé la charge utile, pas le point d'entrée. Tant que la faille d'origine n'est pas fermée et les identifiants renouvelés, l'attaquant revient.

Puis-je simplement restaurer une sauvegarde ?

Seulement si elle est antérieure à l'infection et si vous corrigez la faille juste après. La plupart des compromissions passent inaperçues des semaines durant.

Une extension de sécurité suffit-elle ?

Pour retirer les charges visibles, souvent. Pour trouver les portes dérobées et identifier le point d'entrée, non — cela demande de lire les journaux et les dates de modification.