Dans le cadre de mon service de maintenance, j’ai eu à traiter récemment un incident de sécurité particulièrement virulent : un site WordPress piraté, réinfecté à plusieurs reprises. Ces désagréments sont pour moi l’occasion d’apprendre et c’est aussi assez gratifiant d’arriver à résoudre ce genre de problème un peu compliqué.
Un site que je connaissais bien
Tout commence avec un site que j’avais conçu il y a plusieurs années pour une structure du secteur culturel, sous WordPress avec le thème DIVI. J’en ai assuré la maintenance pendant un temps, puis, à la demande de l’équipe, je leur ai transmis les clés : je leur ai expliqué comment gérer eux-mêmes les mises à jour, en insistant sur l’importance de bien faire les mises à jour.
Quelques années passent. Une nouvelle chargée de communication me recontacte : le site est lent et rencontre des problèmes, des messages d’alerte…
Le diagnostic : l’accumulation de tout ce qu’il ne faut pas faire
En regardant de plus près, je tombe sur diverses problèmes :
- une série de plugins inutiles ;
- plusieurs plugins de cache activés en même temps — ce qui, loin d’accélérer le site, génère des conflits ;
- des plugins de traitement d’images activés en parallèle ;
- et surtout, des images ajoutées en PNG, 300 dpi, mode CMJN, 5000 pixels de large. Autrement dit : des fichiers pensés pour l’impression, là où il aurait fallu du JPEG/WebP en RVB, dimensionné pour le web.
- Des thèmes et des plugins non mis à jour.
Bref, le cocktail détonnant : un site qu’on alourdit en croyant l’optimiser, et qu’on fragilise faute de suivi.
Je commence par un gros nettoyage : suppression des plugins redondants, remise en ordre, et passage à une version de PHP à jour — le site tournait encore sous PHP 7.4, qui n’est plus maintenu depuis longtemps. Reprise de la maintenance, tout semblait aller mieux, le site était de nouveau plus rapide.
L’attaque se déclare
Quelque temps plus tard, le site ne répond plus du tout. À la place : l’écran d’installation de WordPress. Choix de la langue, création du compte administrateur principal — comme sur une installation neuve.
Concrètement, le wp-config.php avait été modifié pour pointer vers une base de données qui n’était plus la bonne, celle de hackers. Le mécanisme exact reste à confirmer, mais le scénario plausible est le suivant : si l’on complète naïvement cet écran d’installation, on risque de recréer un compte administrateur dans une base contrôlée par l’attaquant. Je me garde de toute affirmation définitive sur leurs intentions — ce que je sais, c’est qu’il ne fallait surtout pas cliquer pour « réinstaller ».
La réponse de crise
Alerte maximale. Je passe en mode confinement et nettoyage en profondeur :
- changement de tous les mots de passe : FTP, compte hébergeur, accès WordPress ;
- suppression de la base de données compromise et création d’une base saine ;
- restauration d’une archive antérieure (datant d’une quinzaine de jours, donc en amont de l’incident visible) ;
- installation de Wordfence pour scanner l’ensemble.
Wordfence remonte aussitôt une série de fichiers suspects. Je nettoie. Et le lendemain, le signal qui ne trompe pas : un nouvel administrateur apparaît, avec une adresse e-mail en .ru. Le site est toujours compromis.
Le piège des réinfections
C’est le moment clé — et le plus instructif. Quand un compte admin pirate réapparaît après nettoyage, ça veut dire une chose : la porte d’entrée est toujours ouverte quelque part. Supprimer les fichiers détectés et changer les mots de passe ne suffit pas si on n’a pas identifié par où l’attaquant entre.
Je relance donc nouveau nettoyage, nouveaux mots de passe partout, et activation de tous les réglages de sécurité possibles pour masquer ce qui pouvait l’être et durcir les accès. Quelques symptômes étranges subsistent au passage — des typographies qui sautent, un menu cassé — autant de séquelles à réparer une à une.
Le résidu visible : Google
Dernier front, et non des moindres : dans les résultats de recherche Google, la page d’accueil s’affichait avec un titre et une méta-description en turc — signature typique d’un piratage SEO (le spam injecté pour détourner le référencement vers d’autres contenus).
Point important que j’ai appris à mes dépens : ce contenu turc dans les résultats Google ne signifie pas forcément qu’il est encore dans la page. Une fois le site nettoyé, c’est souvent un cache obsolète de Google : le moteur affiche encore l’ancienne version tant qu’il n’a pas re-exploré le site. La solution passe par la Google Search Console (demande d’inspection et de réindexation), mais encore faut-il que le serveur réponde correctement au robot — un point à vérifier soigneusement, car une erreur de connexion côté serveur peut tout bloquer.
Ce que je retiens
Le site est aujourd’hui de nouveau fonctionnel et propre en surface. Mais je préfère être honnête : sur ce type d’incident, tant qu’on n’a pas formellement identifié le point d’entrée, on ne peut pas garantir à 100 % qu’une réinfection ne reviendra pas. La vigilance reste de mise, avec une surveillance active (re-scans réguliers, contrôle des comptes admin, des crons et des fichiers récemment modifiés).
Je confirme donc par cette expérience :
- La maintenance n’est pas optionnelle. Un WordPress laissé sans mises à jour finit toujours par être compromis. La question n’est pas « si », mais « quand ».
- PHP obsolète, plugins empilés, médias non optimisés : ce ne sont pas que des problèmes de performance, ce sont des facteurs de fragilité globale.
- Un nettoyage de surface ne suffit pas. Supprimer des fichiers et changer les mots de passe sans trouver le vecteur d’entrée, c’est tourner en rond.
- Le référencement est une victime collatérale du piratage. Restaurer le site techniquement ne restaure pas instantanément sa visibilité : il faut accompagner Google.
- Important aussi d’avoir des mots de passes différents pour la base, le compte hébergeurs, le FTP les administrateurs et surtout des mots de passe compliqués.
