Enlever virus WordPress : procédure pas à pas avec FTP/SFTP

Un site WordPress infecté, ce n’est pas seulement “un petit souci de lenteur”. Dans les cas fréquents, l’infection sert à injecter des liens douteux, rediriger vers des pages de phishing, ou placer du code dans des fichiers qui n’ont rien à voir avec votre thème. Parfois, on voit des pop-ups au lieu de votre contenu, parfois Google ou votre messagerie d’admin commencent à signaler des comportements anormaux, et parfois tout reste discret jusqu’au jour où les visiteurs ne tombent plus sur les bonnes pages.

Quand l’accès à l’admin est perdu ou que l’interface ne permet plus de faire proprement le ménage, le réflexe le plus fiable reste souvent de travailler directement sur les fichiers, via FTP ou SFTP. C’est une approche “bas niveau”, exigeante mais maîtrisable, surtout si vous procédez avec méthode: couper le problème, identifier ce qui a été modifié, nettoyer sans casser votre site, puis sécuriser pour éviter une récidive.

Je vous propose une procédure pas à pas, centrée sur FTP/SFTP, avec les pièges que j’ai vus revenir sur des installations très différentes.

Préparer le terrain avant de toucher aux fichiers

Avant de supprimer quoi que ce soit, prenez le temps de sécuriser votre marge de manœuvre. Un nettoyage réussi dépend souvent de la capacité à revenir en arrière.

Commencez par obtenir ces informations, si vous ne les avez pas déjà:

l’accès FTP/SFTP (hôte, port, identifiant, méthode de chiffrement si vous êtes en SFTP) le chemin exact du dossier WordPress sur le serveur (souvent public_html, parfois un sous-dossier) l’existence d’un dossier “cache” ou d’un “upload” séparé (par exemple wp-content/uploads ou un autre répertoire) le type de votre instance: multisite WordPress, WordPress simple, ou WordPress dans un contexte particulier (répertoire partagé, sous-domaine, etc.)

Ensuite, planifiez une fenêtre d’intervention. En pratique, si votre site tourne en production, vous aurez intérêt à le mettre en “mode maintenance”. Vous pouvez le faire temporairement avec un fichier dans le répertoire racine ou via une option de votre hébergeur. Si vous ne savez pas, au minimum, évitez de tester en public: travaillez sur le site, puis vérifiez en local ou sur un sous-domaine quand c’est possible.

Télécharger une copie complète (oui, vraiment)

La règle que je répète à chaque fois: avant le moindre effacement, faites un backup complet des fichiers WordPress et de vos contenus. En FTP/SFTP, cela signifie télécharger les dossiers importants depuis la racine WordPress, au minimum:

wp-content (thèmes, plugins, uploads, mu-plugins si présents) wp-includes les fichiers racine: wp-config.php, index.php, wp-load.php et tout ce qui traîne dans le dossier principal

Si le site est gros, attendez-vous à un temps de copie significatif. Dans plusieurs cas d’infection, la taille des uploads n’est pas négligeable, et c’est normal.

Important: ne mélangez pas “copie pour analyse” et “copie finale”. Une copie unique et horodatée, c’est votre point de retour.

Étape 1: vérifier l’hypothèse la plus probable

Les virus WordPress se cachent rarement “par magie” dans l’air. En pratique, la majorité des infections passent par des fichiers modifiés: thèmes, plugins, fichiers racine, parfois des scripts dans wp-content/uploads, et plus rarement via le noyau. Même quand le noyau a été touché, on retrouve des traces.

Sur votre serveur, ouvrez en FTP/SFTP le répertoire racine de WordPress et regardez:

les fichiers récemment modifiés (dates d’accès ou dates de modification, selon le client FTP) les fichiers inhabituels ajoutés récemment (fichiers aux noms bizarres, extensions atypiques comme .php5, .phtml, .inc, ou des doublons) des fichiers dans des dossiers qui ne sont pas censés contenir du code malveillant (par exemple dans uploads)

Votre but ici n’est pas de supprimer tout de suite. C’est de repérer le “signal faible”. Un client FTP affiche parfois les dates de modification avec des nuances, mais même un ordre approximatif aide beaucoup.

Où chercher en priorité

Sans tomber dans une liste “magique”, il y a des zones qui reviennent constamment:

wp-content/plugins/ si un plugin a été mal protégé, nullement mis à jour, ou compromis via un autre vecteur wp-content/themes/ si vous avez un thème qui reçoit des mises à jour difficiles, un thème enfant bricolé, ou un thème dont les fichiers ont des dates incohérentes wp-content/uploads/ parce que des fichiers peuvent y être injectés ou dissimulés le dossier racine, surtout wp-config.php et des fichiers additionnels que vous n’avez pas mis là

Si vous voyez des fichiers PHP dans uploads, considérez-le comme une alerte très sérieuse. WordPress autorise le PHP dans uploads seulement si votre configuration serveur le permet. La présence de tels fichiers est donc souvent un signe d’infection, pas “un contenu normal”.

Étape 2: couper la propagation et limiter l’impact

Quand vous soupçonnez une infection active, le plus simple est d’empêcher l’exécution du code suspect pendant que vous analysez.

Il y a plusieurs stratégies, à choisir selon votre situation:

si votre site répond encore à l’accès public, mettez-le en maintenance si vous pouvez, bloquez temporairement l’exécution des fichiers PHP dans des répertoires non attendus (par exemple wp-content/uploads) via .htaccess ou configuration serveur, mais ce n’est pas toujours faisable proprement si l’infection est identifiée dans un fichier unique, vous pouvez le renommer temporairement au lieu de le supprimer, pour vérifier que les symptômes disparaissent

Renommer au lieu de supprimer est un détail pratique. Une suppression peut être irréversible si vous avez supprimé le “bon” fichier par erreur. Un renommage vous permet de re-tester rapidement.

Vérification rapide, sans casser

Après chaque action importante, testez. Ouvrez votre site, mais aussi quelques pages sensibles:

la page d’accueil une page “public” (articles ou pages) une page qui déclenche souvent du code (par exemple des formulaires, recherche, catégories) si possible, les pages d’admin (même si vous n’y accédez pas, tentez une redirection ou observez les erreurs)

Si votre client ou votre réseau déclenche des comportements dus à un cache ou à un CDN, testez aussi en navigation privée. Les infections peuvent être “cachées” par une mise en cache agressive.

Étape 3: isoler les fichiers modifiés et repérer les incohérences

À ce stade, vous avez votre backup, le site potentiellement en maintenance, et une première cartographie des fichiers “bizarres”. Maintenant, vous devez faire le tri.

Le piège fréquent, c’est de supprimer un fichier suspect sans comprendre son rôle. WordPress est tolérant, mais pas au point de survivre à n’importe quel effacement. Pour éviter de casser votre installation, procédez par vérification.

Les signaux de code malveillant dans des fichiers PHP

Ouvrez les fichiers suspects dans un éditeur de texte local (pas juste dans l’aperçu FTP). Cherchez des motifs typiques d’infection. Sans entrer dans une signature universelle, on retrouve souvent:

du code base64 ou gzinflate, avec déploiement dynamique des fonctions d’exécution (eval, str_rot13 parfois, ou d’autres mécanismes d’obfuscation) du code qui charge du contenu distant ou écrit des fichiers sur le serveur des redirections vers des domaines externes, souvent cachées dans des conditions “si un certain paramètre existe” des fichiers “dans le vide”, avec des en-têtes étranges ou des blocs qui ne ressemblent pas à du PHP normal de thème ou plugin

Quand vous voyez une structure qui ressemble à de l’obfuscation, prenez une capture et notez le nom du fichier, le chemin exact, et la date de modification. Cela vous servira si vous devez demander de l’aide à votre hébergeur ou si vous réinstallez proprement.

Gérer les cas trompeurs

Certains thèmes ou plugins légitimes utilisent des fonctions avancées et de la compression ou des bibliothèques. Ce qui fait basculer vers “malveillant”, c’est généralement le contexte: emplacement inattendu, ajout récent, et surtout présence de logique d’exfiltration ou de redirection cachée.

J’ai déjà vu des infections qui se cachaient dans un fichier qui semblait “presque” normal, parce que l’attaque avait ajouté seulement quelques lignes au bas du fichier. À l’inverse, j’ai aussi vu des faux positifs côté antivirus sur des fichiers très spécifiques. La méthode la plus fiable reste la comparaison et la compréhension.

Étape 4: nettoyer intelligemment, sans casser WordPress

Une fois que vous identifiez les fichiers suspects, vous avez deux stratégies principales: supprimer ce qui est clairement malveillant, ou reconstruire à partir de versions saines.

Dans une procédure FTP/SFTP, la reconstruction est souvent l’approche la plus robuste. Elle demande du temps, mais elle réduit le risque d’oublier une petite charge dans un plugin ou un thème.

Variante “reconstruction” sur noyau, thèmes et plugins

Le noyau WordPress (wp-includes et les fichiers racine) peut être réinstallé depuis une version saine, sans toucher à vos contenus. Les contenus, c’est wp-content et en particulier vos uploads.

Mais si vous suspectez aussi des modifications dans wp-content, alors la reconstruction doit inclure vos thèmes et plugins.

Le trade-off est simple:

reconstruction complète: plus sûre, plus longue suppression ciblée: plus rapide, mais demande une bonne lecture des fichiers

Si vous voulez minimiser le risque résiduel, je recommande, dans le contexte “site infecté”, de reconstruire thèmes et plugins depuis des sources propres, plutôt que de “corriger” fichier par fichier.

En pratique, qu’effacer et qu’épargner

Vos contenus médias sont souvent à préserver, même s’ils hébergent parfois des fichiers malveillants. La question devient alors: est-ce que le problème vient du dossier uploads et comment ?

Une approche prudente consiste à:

garder vos uploads mais vérifier la présence de fichiers PHP ou d’extensions anormales supprimer uniquement les fichiers clairement identifiés comme suspects si vous constatez une contamination massive dans uploads, la meilleure stratégie peut être de régénérer le dossier d’uploads depuis le backup, puis de filtrer ce qui est mauvais

Si vous n’êtes pas sûr à 100 pour cent, ne supprimez pas “au hasard”. Faites plutôt des suppressions limitées et testez.

Étape 5: vérifier et restaurer wp-config.php et les fichiers racine

wp-config.php contient vos identifiants et votre base de données. Si vous suspectez un passage de l’infection via ce fichier, il faut traiter le cas avec une attention particulière.

Deux choses importantes:

Ne l’éditez pas “en aveugle” Comparez avec le contenu de votre backup

Si vous avez une infection, certains scripts essaient de se cacher en modifiant quelques lignes dans wp-config.php, ou en ajoutant un require qui charge un fichier malveillant ailleurs. Cherchez l’ajout de code en dehors de la configuration attendue.

Si vous devez restaurer wp-config.php, faites-le depuis votre backup, puis vérifiez que les clés, préfixes de tables, et variables de configuration sont cohérentes. Si votre base a été compromise, la simple restauration peut ne pas suffire, mais elle évite au moins des erreurs de connexion.

Les fichiers racine ajoutés récemment

Les infections ajoutent parfois des fichiers dans le dossier principal, et WordPress les exécute si la configuration serveur le permet. Examinez tout ce qui a été créé récemment:

fichiers PHP additionnels fichiers .txt ou .log qui semblent “servir” de contenu au code fichiers aux noms imitant des fichiers WordPress mais avec une variation légère

Quand un fichier vous semble douteux, renommez-le d’abord. Si le comportement disparaît, vous avez de fortes chances d’être sur la bonne piste.

Étape 6: nettoyer thème et plugins, puis vérifier les dépendances

Si l’infection vient d’un plugin ou d’un thème compromis, ce point devient central. Supprimer les fichiers malveillants dans le thème peut suffire, mais souvent l’infection a touché plusieurs éléments.

Procédure pratique de tri

Dans wp-content/plugins/, regardez les plugins installés et leurs dates de modification. Si vous voyez un plugin installé très récemment et qu’il n’existait pas avant l’incident, c’est un suspect naturel.

Dans wp-content/themes/, vérifiez les thèmes actifs et aussi les thèmes inactifs. J’ai déjà vu un thème inactif infecté, et le malware déclenchait le chargement en fonction d’une condition (par exemple un paramètre dans l’URL).

À ce stade, deux choix:

désactiver puis re-télécharger les thèmes et plugins suspects depuis les sources officielles reconstruire la structure depuis une version saine de votre thème et plugin, puis remplacer uniquement ce qui a été modifié

Dans la réalité, la reconstruction est plus simple si vous avez un fichier de référence côté versionning, ou si vous connaissez exactement l’origine de vos thèmes et plugins.

Étape 7: s’occuper de la base de données sans tout casser

La plupart des procédures “FTP only” oublient la base de données. Or, beaucoup d’infections injectent dans la base: options WordPress, utilisateurs administrateurs créés, contenus modifiés, redirections ajoutées.

Même si vous nettoyez les fichiers, il faut vérifier la base. Ici, vous pouvez faire deux choses:

utiliser votre outil d’hébergement (phpMyAdmin, scripts de l’hébergeur) ou vous limiter au niveau fichiers pour une première phase, puis reprendre base ensuite

Si vous avez accès à phpMyAdmin, cherchez en priorité:

utilisateurs ajoutés ou rôles admin options WordPress anormales tables qui contiennent du contenu injecté

Le point crucial, c’est d’éviter la suppression “à l’aveugle”. Faites des exports des tables touchées avant toute manipulation, surtout sur de vieux sites.

Étape 8: rotation des accès et durcissement

Nettoyer ne sert à rien si l’accès qui a permis l’infection reste vulnérable. Les infections sont souvent un symptôme, pas la cause unique. La cause la plus fréquente reste un accès faible: mot de passe réutilisé, compte admin partagé, plugin obsolète, ou une faille de thème.

Une fois le site nettoyé, prenez quelques mesures concrètes:

changez les mots de passe WordPress, FTP/SFTP et aussi ceux de tout compte admin vérifiez les utilisateurs WordPress, supprimez ceux qui ne devraient pas exister mettez à jour thèmes et plugins depuis des versions sûres supprimez les plugins et thèmes inutiles

Le “durcissement” ne doit pas forcément être lourd. Parfois, une mise à jour et un mot de passe robuste réduisent drastiquement les risques.

Un détail qui change tout: vérifier les comptes SFTP

Beaucoup de gens pensent uniquement au mot de passe WordPress. Pourtant, si un attaquant a accès en FTP/SFTP, il peut réinfecter même après nettoyage. Assurez-vous que les identifiants SFTP ne sont plus valables, et que l’accès est limité au minimum de répertoires nécessaire.

Procédure pas à pas récapitulative (FTP/SFTP)

Je vous remets le fil logique, sous forme de mini-séquence. Elle n’a pas vocation à être une “recette universelle”, mais elle suit ce qui marche le plus souvent sans se perdre dans les détails.

Sauvegardez complètement vos fichiers WordPress, téléchargez une copie locale, puis mettez le site en maintenance si possible. Parcourez le répertoire WordPress et repérez les fichiers ajoutés ou modifiés récemment, surtout dans wp-content/plugins, wp-content/themes et wp-content/uploads. Ouvrez les fichiers suspects en local, identifiez du code obfusqué, des redirections externes ou des chargements dynamiques, puis renommez ou retirez uniquement ce qui est clairement malveillant. Réinstallez depuis des sources saines le noyau si vous suspectez des modifications, et reconstruisez thèmes et plugins si l’infection semble liée. Vérifiez la base de données (utilisateurs, options, contenus injectés), puis faites la rotation des mots de passe et la mise à jour de tout ce qui doit l’être.

Si vous suivez ce schéma, vous évitez le piège “je supprime un fichier au hasard puis je crois que c’est fini”.

Cas concrets: trois scénarios fréquents et ce que je fais

1) Accès admin impossible, site redirige vers des domaines externes

Quand l’accès admin ne marche plus et que le site redirige, je commence par stopper l’exécution du code suspect dans le fichier racine ou le thème actif. En FTP/SFTP, renommer un fichier déclenche souvent un retour à la normale. Ensuite seulement, je fais le ménage complet: reconstruction du thème actif et des plugins récemment modifiés.

Ce scénario a tendance à être “rapide” si vous identifiez le point d’injection, mais il exige une vérification base derrière.

2) Malware discret, pas de redirection visible, mais des fichiers PHP cachés dans uploads

Ce cas est sournois. Le site peut sembler correct pour un utilisateur lambda, alors que des requêtes déclenchent https://gardewp.fr/ du contenu malveillant via des fichiers dans uploads. Ici, je préfère une stratégie de tri, suppression ciblée des fichiers PHP suspects, puis durcissement pour empêcher l’exécution de PHP dans uploads si votre configuration serveur le permet. Ensuite, je vérifie les plugins et thèmes pour voir comment l’accès a été obtenu.

3) Plugin ou thème “a priori légitime” mais modifié de manière incohérente

Quand un plugin est connu et pourtant des morceaux semblent ajoutés, je ne m’acharne pas à “corriger”. Je reconstruis depuis la version propre du plugin, je remplace le dossier entier dans wp-content/plugins, puis je teste. Si le problème revient, c’est un autre vecteur, ou le malware est ailleurs, base de données incluse.

Cette approche évite le syndrome du patch imparfait.

Pièges courants avec FTP/SFTP (et comment les contourner)

Le nettoyage via fichiers fonctionne, mais les erreurs sont faciles.

Supprimer des dossiers “qui ressemblent à des caches” alors qu’ils contiennent des contenus. WordPress a plusieurs dossiers internes, et certains caches peuvent être nécessaires selon vos configurations. Avant de supprimer, vérifiez le rôle du dossier et testez. Éditer wp-config.php sans comparaison avec le backup. Un petit ajout de ligne peut casser le site ou ouvrir une porte. Oublier un plugin inactif. Les infections n’ont pas besoin que le plugin soit actif pour être une source de déclenchement, surtout si la logique existe dans le thème ou dans une option base. Se contenter des fichiers. Une infection qui injecte en base peut survivre à un nettoyage “FTP only”.

Il y a aussi le piège inverse, plus rare mais réel: un antivirus ou une analyse superficielle qui accuse le mauvais fichier. Dans ce cas, reconstruire depuis une source saine devient votre filet de sécurité.

Comment confirmer que le site est vraiment propre

Après nettoyage, vous devez valider au lieu d’espérer.

Vérifiez d’abord le comportement: redirections disparues, formulaires qui fonctionnent, pages qui s’affichent correctement. Ensuite, vérifiez l’intégrité.

Concrètement, je fais:

comparaison visuelle des dossiers wp-includes et fichiers racine contre la version attendue vérification des dates de modification: le “profil” des fichiers redevient cohérent re-téléchargement et reconstruction des éléments suspects pour éliminer les restes contrôle des utilisateurs et options en base tests sur plusieurs navigateurs, idéalement en navigation privée

Si votre hébergeur ou un outil de sécurité vous signale encore des comportements, prenez-le comme un indice, pas comme une vérité absolue. Certains faux positifs surviennent, mais la cohérence du diagnostic compte plus que le verdict isolé.

En cas d’urgence: quand vous devez agir vite

Si vous êtes en pleine attaque visible, ou si un client vous met la pression parce que le trafic chute, vous pouvez adopter une approche “urgence” sans sacrifier la qualité.

Vous renforcez vite, puis vous nettoyez proprement ensuite:

couper le site via maintenance isoler et renommer le point de déclenchement évident reconstruire thèmes et plugins, au minimum ceux récemment modifiés sauvegarder et reporter la base dans un second temps si vous n’avez pas l’accès complet immédiatement

Cela peut vous faire gagner des heures, sans vous laisser dans un nettoyage partiel trop long.

Questions que vous devriez vous poser avant de commencer

Si vous ne devez retenir que des réflexes, gardez ceux-ci:

Est-ce que l’infection a commencé après une mise à jour, une installation de plugin, ou un changement de thème ? Avez-vous des fichiers récemment ajoutés qui n’ont rien à faire dans uploads ou dans le dossier racine ? Les utilisateurs WordPress ont-ils été modifiés, créés, ou dopés en rôle ? Vos identifiants FTP/SFTP sont-ils protégés avec des mots de passe solides et uniques ? Votre site utilise-t-il un cache ou un CDN qui peut masquer des tests ?

Ces réponses orientent votre stratégie. Elles évitent de reconstruire trop ou pas assez.

Sécurité après nettoyage: ce qui évite le “retour du virus”

Une fois le site propre, l’objectif devient de réduire les surfaces d’attaque.

Je recommande un plan simple, sans complication:

mise à jour régulière des thèmes et plugins, suppression des éléments inutiles mots de passe uniques, et gestion stricte des comptes admin limitation d’accès si votre hébergeur propose des règles, par exemple restrictions sur l’URL de connexion admin surveillance des fichiers modifiés, au moins une vérification périodique via votre client FTP ou un outil de monitoring

Le plus gros frein, c’est la négligence. Le second, c’est la gestion trop “au feeling”. Avec une procédure reproductible, vous gagnez en sérénité, même si vous ne tombez pas sur le même type d’infection deux fois.

Si vous voulez, décrivez-moi le symptôme principal (redirige, page blanche, message d’erreur, fichiers suspects repérés, accès admin HS ou non) et votre structure (WordPress simple ou multisite, où se trouve le dossier sur le serveur). Je pourrai vous proposer un plan de tri plus ciblé pour vos cas, toujours avec une logique FTP/SFTP et en minimisant les risques de casser le site.