Sécurité web

Pourquoi un site WordPress se réinfecte après nettoyage

Une porte dérobée décrite par Sucuri en octobre 2026 se reconstruit dès qu'on en supprime un morceau. Ce qu'elle montre sur les réinfections, et les endroits à vérifier.

LALoïs Armand31 octobre 2026 · 4 min de lecture

Nettoyer un site piraté et voir l'infection revenir deux jours plus tard : c'est l'une des situations les plus décourageantes qui soient. Le 1er octobre 2026, Sucuri a décrit un malware WordPress qui en donne une explication spectaculaire : une porte dérobée, surnommée « SC », conçue pour se reconstruire dès qu'on en supprime un morceau. Elle illustre bien pourquoi un site piraté se nettoie en entier ou pas du tout.

Un malware en plusieurs exemplaires

Cette porte dérobée ne tient pas dans un seul fichier. Elle se répartit à plusieurs endroits, et chaque partie sait recréer les autres :

  • dans les fichiers : un fichier .user.ini qui charge du code avant chaque page, des copies dans wp-content, dans un thème, dans mu-plugins (les extensions « obligatoires », invisibles dans la liste habituelle) et dans un faux plugin ;
  • dans la base de données : une copie compressée et encodée du code, prête à être redéployée ;
  • dans la mémoire du serveur, quand elle est disponible : une copie qui survit même à la suppression des fichiers et au nettoyage de la base ;
  • dans les tâches planifiées de WordPress : des tâches aux noms aléatoires qui relancent la reconstruction.

Sucuri résume ainsi : supprimer une seule partie conduit les autres à la recréer.

Pourquoi un nettoyage partiel échoue

La plupart des nettoyages faits à la main, ou par une extension de sécurité, traitent ce qu'ils voient : un fichier signalé, un compte inconnu. C'est utile, mais si une seule copie reste dans la base ou une tâche planifiée, l'infection revient. Ce n'est pas propre à ce malware : la réinfection rapide est presque toujours le signe qu'une porte dérobée a survécu.

Les endroits à vérifier

  1. Le fichier .user.ini à la racine, et toute directive auto_prepend_file que vous n'avez pas mise.
  2. Le dossier wp-content/mu-plugins, que peu de propriétaires de sites ouvrent.
  3. Les fichiers advanced-cache.php ou functions.php modifiés récemment.
  4. Les tâches planifiées, avec une extension de type « WP Crontrol » ou en ligne de commande.
  5. La table des options de la base de données, à la recherche de longues chaînes encodées.
  6. Les comptes administrateurs, y compris ceux cachés de l'interface.

La bonne méthode

Un nettoyage qui tient se fait dans un ordre précis : sauvegarde de l'état actuel, recherche de toutes les copies avant d'en supprimer une seule, suppression simultanée, redémarrage des processus PHP pour vider la mémoire, changement de tous les accès, puis fermeture de la faille d'origine.

C'est ce que comprend notre nettoyage complet, garanti 30 jours : si la même infection revient, on intervient de nouveau sans frais. Pour les sites qui ont déjà connu une réinfection, voyez aussi notre page WordPress piraté.

Source : [The Hacker News, d'après Sucuri](https://thehackernews.com/2026/10/wordpress-backdoor-rebuilds-itself.html), 1er octobre 2026.

À lire aussi

Passons à l'action

Une question sur ce sujet pour votre structure ? Échangeons 30 minutes, gratuitement et sans engagement.

Planifier un appel gratuit →