Désinfecter un site WordPress : le protocole pour éliminer un logiciel malveillant sans récidive

Lancer un analyseur, voir trois fichiers disparaître et croire l’affaire réglée : c’est le scénario classique d’une réinfection. Une semaine plus tard, le même code revient, parce qu’une porte dérobée est restée tapie dans les médias, dans la base de données ou dans une tâche programmée. Pour nettoyer un malware WordPress pour de bon, il faut une méthode, pas un bouton.

Référenceur, agence de marketing numérique francophone de Belgique et du Luxembourg, mène à distance des désinfections complètes et documentées, du premier diagnostic à la remise en ligne. Ce guide présente notre protocole, les vérifications que vous pouvez faire vous-même et celles qu’il vaut mieux laisser à un spécialiste ou à votre hébergeur.

Commencez par un premier balayage avec notre outil d’analyse de sécurité gratuit :

Vous préférez déléguer tout de suite? Notre page sur le nettoyage d’un site WordPress piraté décrit l’intervention de A à Z.

Avant de supprimer quoi que ce soit, conservez les preuves

Effacer tout ce qui semble anormal est un réflexe compréhensible, mais il fait disparaître les indices qui expliquent l’attaque. La toute première étape consiste donc à faire une copie intégrale du site infecté, fichiers et base de données, à l’entreposer hors du serveur et à lui donner un nom qui ne prête à aucune confusion. Cette copie servira à l’enquête, jamais à une restauration.

Demandez ensuite à votre hébergeur les journaux d’accès du serveur Web ainsi que l’historique des connexions FTP, SFTP et SSH. Mis en parallèle avec les dates de modification des fichiers, ils révèlent souvent le moment et le moyen de l’intrusion : extension périmée, mot de passe recyclé, compte d’une ancienne agence jamais fermé.

Changez enfin tous les mots de passe, en travaillant depuis un ordinateur sain : panneau d’hébergement, FTP, base de données, comptes WordPress et boîtes de courriel liées au site. Un pirate qui lit encore votre courrier pourrait sinon réinitialiser vos nouveaux accès sans que vous le sachiez.

Premier état des lieux avec WP-CLI

Avec un accès SSH, WP-CLI fournit un portrait fiable de l’installation. D’après la documentation de WP-CLI, la vérification du noyau confronte chaque fichier aux sommes de contrôle que WordPress.org publie pour votre version.

wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

L’option --include-root étend la vérification aux fichiers inconnus déposés à la racine. Les extensions publiées sur WordPress.org sont comparées à leur version officielle; une extension commerciale ou faite sur mesure échappe toutefois à ce contrôle et doit être retéléchargée chez son éditeur ou relue attentivement.

Les deux dernières commandes listent les administrateurs et les événements cron. Un compte que personne n’identifie ou une tâche au nom farfelu doit être réglé avant toute réinstallation : autrement, il recréera le problème aussitôt.

Six cachettes où le code malveillant survit

Les sommes de contrôle ne couvrent ni les médias, ni la configuration, ni les extensions « must-use ». Ce sont précisément les endroits que les attaquants privilégient pour revenir après un nettoyage superficiel.

Emplacement	Indice typique	Vérification recommandée
wp-content/uploads	Fichier PHP déguisé en image ou en cache	Lister tous les .php : il ne devrait y en avoir aucun
Fichiers .htaccess	Règle de réécriture vers un script caché ou un domaine externe	Comparer au bloc WordPress standard, dossier par dossier
wp-config.php	Instruction include inconnue ou code ajouté en tête de fichier	Relire en entier et ne garder que les réglages connus
wp-content/mu-plugins	Extension active qui n’apparaît pas dans la liste habituelle	Ouvrir le dossier et justifier chaque fichier
Thèmes (parent et enfant)	Code inséré dans functions.php, header.php ou footer.php	Confronter à l’archive téléchargée chez l’éditeur
Tâches cron	Événement qui réécrit le code malveillant chaque nuit	Liste WP-CLI, suppression des crochets inconnus

find wp-content/uploads -type f -name "*.php"

Selon la documentation de WordPress, tout fichier placé dans wp-content/mu-plugins se charge automatiquement, ne peut pas être désactivé depuis l’administration et n’affiche aucun avis de mise à jour. Une planque idéale pour qui veut passer inaperçu.

À l’intérieur des fichiers, repérez les longues chaînes de caractères illisibles associées à base64_decode, eval ou gzinflate. Ces fonctions ont aussi des usages légitimes : isolez le fichier en quarantaine plutôt que de le supprimer sans savoir à quoi il sert.

Assainir la base de données sans briser le site

Des fichiers impeccables ne servent à rien si la base réinjecte le code à chaque chargement de page. Dans la table wp_options, assurez-vous que siteurl et home pointent exactement vers votre domaine et qu’aucune option ne charge un script hébergé ailleurs.

Inspectez ensuite wp_posts : balises script ou iframe, liens vers des casinos ou des pharmacies en ligne, pages rédigées en caractères japonais. Sur un site bilingue, contrôlez la version française et la version anglaise : l’injection ne vise parfois qu’une seule langue.

Pour les comptes d’utilisateurs, notez la date de création de chaque compte douteux avant de le retirer. Cette information aide à dater l’intrusion et à choisir une éventuelle sauvegarde saine.

Reconstruire sur des fondations saines

Une fois l’inventaire terminé, on remplace au lieu de réparer fichier par fichier. L’ordre compte : chaque étape suppose que la précédente est propre.

1. Noyau : écrasez wp-admin et wp-includes avec une copie officielle de WordPress.org, dans la même version.
2. Extensions : supprimez chaque dossier et réinstallez à partir de WordPress.org ou du site de l’éditeur, jamais à partir d’une version « nulled ».
3. Thème : réinstallez le thème parent d’origine et relisez le thème enfant ligne par ligne.
4. Ménage : retirez les thèmes et extensions désactivés, les vieilles copies du site et les sous-dossiers de test oubliés.
5. Clés de sécurité : régénérez les salts avec wp config shuffle-salts; toutes les sessions sont fermées, y compris celle de l’intrus.
6. Contrôle final : relancez les vérifications WP-CLI, puis testez le site en navigation privée, sur cellulaire et dans chaque langue.

Prévenez votre équipe : tout le monde devra se reconnecter. Si le site est trop ancien ou trop bricolé pour être réinstallé de façon fiable, une refonte du site WordPress demande parfois moins d’efforts que des nettoyages à répétition.

Reste à fermer la faille : mises à jour du noyau, des extensions, du thème et de PHP, authentification à deux facteurs, et ajout de define( 'DISALLOW_FILE_EDIT', true ); dans wp-config.php pour neutraliser l’éditeur de fichiers intégré.

Loi 25 et signalements : les démarches à ne pas oublier

Si votre site recueille des renseignements personnels (formulaire de contact, réservations, espace membres, commandes), un incident de confidentialité peut entraîner des obligations. Au Québec, la Loi 25 demande de prendre rapidement des mesures pour réduire le risque, d’aviser avec diligence la Commission d’accès à l’information et les personnes concernées lorsque l’incident présente un risque de préjudice sérieux, et d’inscrire tout incident dans un registre.

Hors Québec, ou pour les activités commerciales qui dépassent les frontières de la province, la LPRPDE fédérale prévoit une déclaration au Commissariat à la protection de la vie privée du Canada en cas de risque réel de préjudice grave. Notre page sur la Loi 25 donne le contexte général; ce guide ne constitue pas un avis juridique.

Côté cybersécurité, le Centre canadien pour la cybersécurité reçoit les signalements d’incidents. Une plainte à la police reste une démarche distincte, utile en cas de pertes financières ou de demande de rançon.

Une intervention menée à distance, par visioconférence

Intervenir sur un WordPress infecté n’exige aucun déplacement : tout se fait par visioconférence et avec des accès délégués. Un premier appel sert à dresser la liste des accès, à décider de ce qui doit être conservé comme preuve et à répartir les rôles avec votre hébergeur.

Pendant la désinfection, deux formules sont possibles : vous regardez le travail se faire en partage d’écran, ou vous nous laissez travailler seuls avec des accès provisoires, que vous fermez une fois le site remis en ligne. Dans les deux cas, un compte rendu écrit liste ce qui a été retiré (fichiers, comptes) et la brèche la plus vraisemblable.

Une courte séance de formation, enregistrée, donne ensuite à votre équipe les bons réflexes, et un suivi mensuel peut encadrer mises à jour et sauvegardes, à des heures qui tiennent compte du décalage horaire.

Désinfecter un site WordPress : questions fréquentes

Restaurer la sauvegarde d’hier, ça ne suffit pas?

Rarement. Un code malveillant peut dormir plusieurs semaines avant de se manifester : la copie d’hier contient alors la même porte dérobée. Même une sauvegarde antérieure à l’attaque laisse la faille d’origine ouverte et les identifiants volés valides. Restaurez seulement après avoir daté l’attaque, corrigé la faille et changé tous les accès.

Mon hébergeur peut-il s’en occuper?

Il arrive qu’un hébergeur balaie les fichiers, ou mette un site infecté hors ligne pour préserver ses autres clients. Ce qui se trouve dans l’installation WordPress reste toutefois, le plus souvent, sous votre responsabilité. Demandez-leur au moins les journaux, une sauvegarde côté serveur et la liste des fichiers modifiés récemment : ces éléments rendent le nettoyage beaucoup plus précis.

Une extension de sécurité peut-elle tout régler seule?

Elle reconnaît les signatures connues, mais pas forcément un code inédit, un script caché dans la base ou un administrateur qui a l’air légitime. Pour une désinfection durable, combinez l’analyseur, les sommes de contrôle WP-CLI, l’inspection des cachettes sensibles et une réinstallation propre. L’extension sert ensuite à la surveillance.

Dois-je aviser la Commission d’accès à l’information?

Tout dépend des renseignements exposés. Si l’intrus a pu accéder à des renseignements personnels et que l’incident présente un risque de préjudice sérieux, la Loi 25 prévoit un avis à la CAI et aux personnes concernées. Un site vitrine sans formulaire ni compte client ne présente pas le même profil qu’une boutique en ligne. Faites-vous conseiller pour votre cas.

Pourquoi le site est-il réinfecté après chaque nettoyage?

Dans la quasi-totalité des cas, quelque chose a été oublié : un PHP glissé parmi les images, un fichier dans mu-plugins, un événement cron, un administrateur caché ou un accès FTP dont le mot de passe n’a pas bougé. La faille d’origine, souvent une extension non mise à jour, peut aussi être restée ouverte. L’inventaire complet doit toujours précéder la réinstallation.

Plusieurs sites partagent mon hébergement : que faire?

Traitez-les comme un seul incident. Sur un même compte, un code malveillant passe facilement d’une installation à l’autre, par exemple de votre site principal à une vieille version de test oubliée. Supprimez les installations inutiles, nettoyez les autres en même temps et donnez un mot de passe distinct à chaque base de données.

Le même code revient sans cesse? Faites d’abord le point avec notre analyse gratuite :

Référenceur, agence de marketing numérique francophone de Belgique et du Luxembourg, passe en revue avec vous les symptômes, les accès disponibles et le protocole adapté à votre installation. Obtenir un diagnostic gratuit.