Désinfecter site WordPress : réinfection en cas d'erreur
Vous avez passé des heures à désinfecter votre site WordPress, et pourtant le malware est revenu en quelques jours. Ce scénario frustrant touche des dizaines de propriétaires de sites chaque semaine - et la cause n'est presque jamais un nouveau piratage, mais une désinfection incomplète.
Le problème est simple à comprendre mais difficile à résoudre sans méthode : un site WordPress compromis contient rarement une seule porte d'entrée. Les attaquants déploient plusieurs mécanismes de persistance - backdoors dissimulées, tâches automatisées, comptes fantômes - pour garantir leur accès même après un nettoyage superficiel. Supprimer le fichier infecté visible ne fait que traiter le symptôme.
Voici les 7 erreurs qui laissent la porte ouverte aux réinfections, et comment les éviter définitivement.
Erreur n°1 - Nettoyer les fichiers visibles sans chercher les backdoors WordPress cachées
La plupart des désinfections se limitent à supprimer les fichiers visiblement modifiés. On repère un index.php altéré, un wp-login.php suspect, on les remplace par les originaux et on pense le travail terminé. C'est exactement ce que les pirates anticipent. Les backdoors WordPress sont dissimulées dans des fichiers aux noms parfaitement anodins - class-wp-cache.php, wp-includes/SimplePie/Parse/Date.php ou encore un fichier déguisé en plugin légitime dans wp-content/plugins.
Ces fichiers contiennent typiquement une fonction eval(base64_decode(...)) qui reconstitue le malware à chaque visite du site. Le code est volontairement obscurci pour échapper aux scans automatiques. Un fichier de quelques lignes peut suffire à retélécharger l'intégralité du payload malveillant depuis un serveur distant, annulant tout le travail de nettoyage en quelques secondes.
Les backdoors utilisent souvent des noms qui imitent les fichiers WordPress légitimes : wp-tmp.php, wp-feed.php, class-wp-widget.php. Sans comparaison méthodique avec les fichiers originaux du core WordPress, il est impossible de distinguer un fichier légitime d'un fichier piégé. Un scan antivirus classique ne détecte que les signatures connues - les backdoors personnalisées passent systématiquement entre les mailles.
Pour traiter cette erreur, comparez chaque fichier du core avec le dépôt officiel WordPress via la commande `wp core verify-checksums` ou un diff récursif. Cette opération prend quelques minutes et révèle immédiatement tout fichier modifié ou ajouté qui ne devrait pas être là.
Erreur n°2 - Ignorer la base de données infectée lors de la désinfection
Un scan sécurité WordPress classique ne vérifie que les fichiers PHP, les thèmes et les plugins. La base de données est rarement inspectée - et les pirates le savent parfaitement. Ils injectent du JavaScript malveillant directement dans les tables wp_posts, wp_options et wp_usermeta, là où aucun plugin de sécurité ne regarde.
Le cas le plus fréquent est un code de redirection injecté dans les champs "siteurl" ou "home" de la table wp_options. L'effet est immédiat : tous les visiteurs sont redirigés vers un site frauduleux, et le propriétaire du site ne comprend pas pourquoi le problème persiste après avoir nettoyé les fichiers. D'autres attaques insèrent des balises script encodées directement dans le contenu des articles, invisibles à l'édition mais exécutées par les navigateurs des visiteurs.
Un fichier wp-config.php compromis représente une menace encore plus grave. Si les identifiants de la base de données ont été exfiltrés, l'attaquant conserve un accès direct à toutes vos données même après un nettoyage complet des fichiers. Il peut modifier les contenus, injecter du code ou créer de nouveaux comptes administrateur à distance.
La solution consiste à rechercher dans la base de données les chaînes suspectes avec des requêtes SQL ciblées sur toutes les tables. Cherchez les termes eval, base64_decode, document.write, iframe src et tout domaine externe inconnu. Changez systématiquement les identifiants de connexion à la base de données après chaque incident.
Erreur n°3 - Garder un plugin vulnérable ou des extensions piratées
Réinstaller WordPress sans mettre à jour chaque plugin vulnérable revient à refermer une porte en laissant la fenêtre grande ouverte. La faille d'entrée initiale - celle qui a permis le piratage - reste exploitable. Les attaquants automatisent leurs scans : si votre site apparaît encore comme vulnérable quelques heures après le nettoyage, il sera compromis de nouveau.
Les thèmes et plugins nulled - ces versions piratées téléchargées gratuitement sur des sites douteux - contiennent presque toujours du code malveillant intégré dès l'installation. Ce code est parfois dormant pendant des semaines avant de s'activer, ce qui rend la corrélation avec le piratage difficile à établir. La règle est absolue : supprimez-les entièrement. Les désactiver ne suffit pas, car le code malveillant peut s'exécuter même sur un plugin désactivé via un appel direct au fichier PHP.
Un cas revient régulièrement : un plugin de formulaire de contact non mis à jour depuis 18 mois qui contenait une faille d'upload. Cette vulnérabilité permettait à n'importe qui de déposer un webshell sur le serveur en 30 secondes, sans authentification. Le plugin fonctionnait parfaitement du point de vue de l'utilisateur - rien ne signalait le danger.
Listez tous vos plugins avec leur version et vérifiez chacun sur la base de données WPScan Vulnerability Database. Supprimez sans hésiter ceux qui sont abandonnés par leurs développeurs - c'est-à-dire sans mise à jour depuis plus de 12 mois. Un plugin abandonné est une bombe à retardement.
Erreur n°4 - Oublier le wp-cron malveillant et les tâches planifiées piégées
Le système wp-cron est l'arme préférée des pirates pour persister après un nettoyage. Le principe est redoutable : une tâche planifiée retélécharge le malware toutes les heures ou tous les jours, de manière totalement silencieuse. Vous nettoyez les fichiers infectés le matin, et le soir le malware est de retour, régénéré par le cron piégé.
Ces tâches cron malveillantes n'apparaissent pas dans l'interface d'administration WordPress. Elles sont enregistrées dans la table wp_options sous la clé "cron", mêlées aux tâches légitimes des plugins installés. Leurs noms de hooks imitent des fonctions WordPress authentiques pour passer inaperçues lors d'une inspection rapide.
Un exemple classique : un hook nommé "wp_update_check_core" - qui ressemble au véritable "wp_version_check" - exécutant un file_get_contents() vers un serveur externe pour recharger le payload malveillant. La différence de nom est subtile, et sans connaissance des hooks WordPress légitimes, cette tâche planifiée passe pour une fonction système normale.
Pour neutraliser cette menace, inspectez la valeur sérialisée de la clé "cron" dans wp_options. Identifiez chaque hook et vérifiez qu'il correspond à un plugin réellement installé sur votre site. Supprimez toutes les entrées orphelines - celles qui ne sont rattachées à aucun plugin ou thème actif.
Erreur n°5 - Ne pas détecter l'utilisateur admin fantôme créé par le pirate
Lors d'une intrusion, les attaquants créent systématiquement un compte utilisateur avec le rôle administrateur. Ce compte fantôme porte souvent un nom discret - "support", "developer", "wp_maintenance" - ou utilise une adresse email jetable. Son seul objectif est de garantir un accès permanent à l'administration du site, même si la faille technique originale est corrigée.
Certains pirates vont plus loin dans la dissimulation. Au lieu de créer un nouveau compte visible, ils modifient le rôle d'un utilisateur existant directement dans la table wp_usermeta. Un simple abonné (subscriber) devient administrateur sans qu'aucune notification ne soit envoyée et sans que le changement n'apparaisse dans les logs WordPress standards.
Un cas observé fréquemment : un compte admin créé avec un ID utilisateur très élevé, par exemple 99847, qui n'apparaît pas sur la première page de la liste des utilisateurs dans l'interface WordPress. Quand votre site compte quelques dizaines d'utilisateurs, personne ne pense à vérifier au-delà de la première page. Le compte fantôme reste actif pendant des mois.
La seule méthode fiable consiste à exécuter une requête SQL directe sur les tables wp_users et wp_usermeta pour lister tous les utilisateurs disposant du rôle administrateur. Vérifiez chaque compte individuellement, supprimez ceux que vous ne reconnaissez pas, et réinitialisez les mots de passe de tous les comptes administrateur légitimes sans exception.
Erreur n°6 - Négliger le serveur et l'environnement autour de WordPress
Un fichier .htaccess modifié à la racine du site ou dans le dossier /wp-content/ peut contenir des redirections malveillantes invisibles. Ces règles redirigent sélectivement les visiteurs venant de Google vers des sites frauduleux, tandis que les accès directs fonctionnent normalement. Le propriétaire du site ne voit rien d'anormal puisqu'il accède au site directement - seuls les visiteurs organiques sont touchés. D'autres règles .htaccess bloquent l'accès aux outils de scan sécurité, empêchant toute détection automatisée.
Les fichiers PHP malveillants placés au-dessus du répertoire WordPress - dans le dossier parent de l'installation - échappent à tous les plugins de sécurité. Ces plugins ne scannent que le répertoire WordPress et ses sous-dossiers. Un script placé un niveau au-dessus reste invisible tout en ayant un accès complet aux fichiers du site.
Sur un hébergement mutualisé, le risque se multiplie. Si un autre site hébergé sur le même serveur est compromis, l'attaquant peut potentiellement accéder à votre installation WordPress par le système de fichiers partagé. La réinfection ne vient alors pas de votre site mais d'un voisin compromis.
Vérifiez les permissions des fichiers - 644 pour les fichiers, 755 pour les dossiers. Scannez le dossier parent de votre installation WordPress. Désactivez l'exécution PHP dans le dossier /wp-content/uploads/ en ajoutant une règle dans le .htaccess de ce répertoire. Ces mesures simples ferment des vecteurs d'attaque souvent négligés.
Comment éviter la réinfection après un nettoyage WordPress réussi
Une fois la désinfection terminée, la priorité immédiate est de couper tous les accès existants. Changez tous les mots de passe sans exception : comptes admin WordPress, accès FTP, identifiants de base de données, panneau de l'hébergeur. Régénérez les clés de sécurité dans wp-config.php - AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et toutes les autres. Cette opération invalide instantanément toutes les sessions actives, y compris celles de l'attaquant.
Installez un pare-feu applicatif (WAF) qui bloque les tentatives d'exploitation avant qu'elles n'atteignent WordPress. La différence avec un plugin de sécurité classique est fondamentale : le WAF intercepte les requêtes malveillantes en amont, tandis qu'un plugin ne fait que détecter les dégâts après coup. C'est la différence entre un gardien à l'entrée et une caméra qui filme le cambriolage.
Une maintenance WordPress préventive avec monitoring continu détecte les modifications suspectes de fichiers en temps réel, avant qu'un malware ne s'installe durablement. La surveillance automatisée compare en permanence l'état des fichiers avec une référence saine et déclenche une alerte à la moindre modification non autorisée.
Enfin, mettez en place des sauvegardes automatiques quotidiennes stockées hors du serveur. En cas de réinfection malgré toutes les précautions, vous pourrez restaurer une version propre datée et identifiée en quelques minutes au lieu de recommencer tout le processus de désinfection.
Conclusion
Désinfecter un site WordPress ne se limite pas à supprimer les fichiers infectés visibles. Chaque backdoor oubliée, chaque tâche cron piégée, chaque utilisateur admin fantôme est une porte que vous laissez ouverte aux pirates. Les 7 erreurs décrites dans cet article sont responsables de la grande majorité des réinfections - et elles ont toutes un point commun : elles exploitent les angles morts d'un nettoyage trop rapide ou trop superficiel.
Si votre site a déjà été réinfecté après un nettoyage, c'est le signe qu'une désinfection professionnelle et méthodique est nécessaire. Pour éviter ces pièges, notre service de nettoyage WordPress garanti à CHF 290.- inclut la suppression de toutes les backdoors et un audit de sécurité complet. Une maintenance WordPress préventive réduit le risque de réinfection grâce à une surveillance 24/7.
Votre site a été réinfecté après un nettoyage ? Contactez-nous pour un diagnostic gratuit et nous évaluerons la situation.
FAQ
Pourquoi mon site WordPress est de nouveau piraté après un nettoyage ?
La cause principale est une désinfection incomplète. Les backdoors WordPress cachées dans des fichiers au nom anodin, les tâches wp-cron malveillantes, les utilisateurs admin fantômes ou une base de données infectée non vérifiée permettent au malware de se réinstaller automatiquement après le nettoyage.
Comment savoir si mon site WordPress contient encore des backdoors ?
Comparez chaque fichier du core WordPress avec les originaux via la commande `wp core verify-checksums`. Inspectez manuellement les dossiers wp-includes et wp-content pour détecter des fichiers PHP suspects contenant des fonctions comme eval(), base64_decode() ou file_get_contents() pointant vers des serveurs externes.
Un plugin de sécurité WordPress suffit-il pour désinfecter un site piraté ?
Non. Les plugins de sécurité détectent les menaces connues mais manquent souvent les backdoors personnalisées, les injections en base de données infectée et les tâches cron piégées. Un scan sécurité WordPress complet nécessite une vérification manuelle des fichiers, de la base de données et des comptes utilisateurs.
Combien de temps faut-il pour désinfecter correctement un site WordPress ?
Une désinfection professionnelle complète prend entre 2 et 6 heures selon la complexité de l'infection. Ce temps inclut l'analyse des backdoors, le nettoyage de la base de données, la vérification de chaque plugin vulnérable, la suppression des utilisateurs fantômes et la sécurisation post-nettoyage.
Faut-il tout réinstaller pour désinfecter un site WordPress ?
Réinstaller WordPress, les thèmes et les plugins depuis des sources propres est la méthode la plus sûre pour éliminer les backdoors des fichiers. Cependant, cela ne suffit pas : il faut aussi nettoyer la base de données, vérifier wp-config.php, supprimer les comptes suspects et changer tous les identifiants d'accès.