Site WordPress piraté : le retour de vacances qui tourne au cauchemar (et comment nettoyer + sécuriser son site)

Retour de vacances. Le soleil, la déconnexion, les mails qui s’accumulent tranquillement pendant deux semaines… et puis ce message d’une cliente, un peu paniqué : « Mon site ne s’affiche plus, il n’y a qu’une page blanche ! Je peux pas non plus me connecter à l’admin. »

C’est exactement la situation que j’ai eue à traiter récemment : un site WordPress piraté. Comme ce cas résume assez bien les pièges classiques (et les bons réflexes) autour de la sécurité WordPress, je me suis dit que ça valait la peine d’en faire un article. Je vous explique comment on diagnostique ce genre de panne, et surtout, je vous donne des pistes concrètes afin de ne jamais s’y retrouver soi-même.

Le symptôme : une page blanche, et rien d’autre

Le site en question affichait une page totalement vide. Pas de message d’erreur, pas de logo, rien. En faisant un clic droit puis « Afficher le code source » (Ctrl+U), même topo : une poignée de lignes vides, aucune trace de code HTML.

Dans l’immense majorité des cas, deux éléments peuvent être en cause :

1. Une erreur PHP fatale (un plugin ou un thème incompatible, une mise à jour qui s’est mal passée, un dépassement de mémoire) ;
2. Un fichier corrompu ou modifié — volontairement ou non.

Sans accès aux outils techniques (hébergeur, FTP), impossible de trancher entre les deux à l’œil nu. C’est là que commence le vrai travail de diagnostic.

Étape 1 : activer le mode debug

Le premier réflexe face à un écran blanc WordPress, c’est d’aller chercher l’information à la source : les logs. Deux options complémentaires :

• Le mode debug de WordPress, activable directement dans le fichier wp-config.php en ajoutant quelques lignes de configuration. Il permet, une fois activé, de consulter un fichier debug.log qui note noir sur blanc chaque erreur PHP rencontrée par le site.
• Le journal d’erreurs de l’hébergeur, indépendant de WordPress. Chez la plupart des hébergeurs, on trouve une interface dédiée dans l’espace client, ou un dossier de logs bruts accessible en FTP. L’avantage : ce journal capture les erreurs même quand WordPress plante avant d’avoir eu le temps de lire sa propre configuration.

Sur ce dossier client, fait notable : même en activant le debug, rien ne s’affichait. Signal qui, avec l’expérience, met la puce à l’oreille — quand absolument rien ne remonte, même pas un message d’erreur basique, il y a de fortes chances que le problème ne soit pas « juste » un bug de plugin.

Étape 2 : remonter la piste jusqu’au fichier suspect

En creusant dans les logs serveur, aucune trace d’erreur PHP classique pour ce site. Ce qui, combiné à la page totalement vide, pointait vers une hypothèse plus préoccupante : et si le fichier index.php lui-même, celui qui sert de porte d’entrée à tout site WordPress, n’était plus le fichier d’origine ?

Vérification faite : bingo. Le contenu du fichier n’avait plus rien à voir avec un index.php WordPress standard. À la place, du code fortement obfusqué (des variables au nom étrange, des fragments de texte encodés, une syntaxe volontairement difficile à lire). Autrement dit : du code malveillant avait été injecté directement dans un fichier cœur du site.

Ce n’était donc pas un bug. C’était un piratage. Et un piratage qui a touché plusieurs fichiers du coeur de WordPress.

Piratage WordPress : comprendre pourquoi (sans se tromper de coupable)

Face à ce genre de découverte, la première réaction est souvent de chercher un responsable immédiat. Dans ce dossier, le webmaster en charge du site a d’ailleurs expliqué à la cliente que le piratage était dû à l’absence de mises à jour depuis plusieurs semaines. Une explication simple, mais un peu trop expéditive. Un site qui n’a pas été mis à jour depuis quelques semaines n’est pas condamné pour autant. Ce qui compte, c’est quelle mise à jour manquait, et si elle corrigeait une faille de sécurité connue.

Dans ce dossier, deux autres pistes méritaient d’être creusées en parallèle :

• Un dossier .git exposé publiquement sur le serveur. Quand un site est déployé via Git sans exclure ce dossier de la partie visible en ligne, il peut potentiellement révéler des informations sensibles à qui sait où chercher. Heureusement bloqué par la configuration serveur ici, mais un signe qu’il faut vérifier systématiquement.
• Un hébergement mutualisé partagé avec un autre site. Sur certaines offres, plusieurs sites d’un même compte client se partagent une partie des ressources serveur. Si l’un des sites du compte est mal sécurisé ou subit une attaque, l’autre peut, dans certains cas, être exposé par ricochet.

La leçon à retenir : un piratage a rarement une seule cause simple. C’est souvent une combinaison de petites négligences qui, ensemble, ouvrent une brèche.

Comment nettoyer un site WordPress piraté sans sauvegarde saine

Autre point essentiel révélé par ce cas : les sauvegardes automatiques de l’hébergeur ne remontaient qu’à 7 jours, et il n’existait aucune sauvegarde externe (via un plugin dédié couplé à un stockage cloud, par exemple). Résultat : impossible de simplement « revenir en arrière » à une version saine antérieure à l’infection, puisque l’infection était antérieure à 7 jours.

Dans ce cas de figure, la remise en état passe obligatoirement par un nettoyage manuel complet :

• Remplacement intégral des fichiers cœur de WordPress par des fichiers d’origine téléchargés depuis la source officielle ;
• Remplacement du thème et de tous les plugins par des versions saines ;
• Recherche de fichiers PHP suspects dans les dossiers qui ne devraient jamais en contenir (comme le dossier des médias) ;
• Vérification de la base de données à la recherche de comptes administrateurs inconnus ou de code injecté dans le contenu ;
• Changement de tous les mots de passe et régénération des clés de sécurité une fois le ménage terminé.

C’est un travail long, minutieux, et qui laisse peu de place à l’approximation : oublier une seule porte dérobée cachée, et le site est réinfecté en quelques jours.

Un nettoyage et une sécurisation du site à la fois longs et coûteux qui auraient pu être évités si le site avait été sécurisé dès sa création.

Sécurité WordPress : ce qu’il faut retenir pour éviter d’en arriver là

Ce cas illustre bien pourquoi la sécurité d’un site WordPress ne se résume pas à « cliquer sur mettre à jour » une fois de temps en temps. La sécurité site WordPress se construit en amont, pas dans l’urgence. Voici les réflexes que je recommande à tous mes clients :

1. Des sauvegardes automatiques ET externalisées. Ne comptez jamais uniquement sur les sauvegardes de votre hébergeur, aussi bonnes soient-elles. Un plugin de sauvegarde qui envoie une copie régulière vers un espace de stockage externe (Google Drive, par exemple) est la meilleure assurance contre un piratage : en cas de souci, on restaure une version saine en quelques minutes au lieu de nettoyer pendant des heures.

2. Des mises à jour régulières, cœur, thème et plugins. Pas besoin de le faire tous les jours, mais un suivi mensuel minimum, avec une attention particulière aux mises à jour de sécurité signalées comme critiques.

3. Des plugins de sécurité actifs. Des solutions comme Wordfence permettent de surveiller les fichiers du site, de détecter les modifications suspectes et de bloquer une partie des tentatives d’intrusion avant même qu’elles n’aboutissent. Deux réglages complémentaires à ne pas négliger : changer l’URL de connexion par défaut (/wp-admin ou /wp-login.php étant les premières cibles de tout bot d’attaque automatisé) pour la remplacer par une adresse personnalisée, et configurer les en-têtes de sécurité HTTP (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options…) qui compliquent l’exploitation de certaines failles côté navigateur.

4. Une vérification de ce qui est exposé publiquement. Dossiers techniques (.git, fichiers de configuration, journaux) ne devraient jamais être accessibles depuis un navigateur.

5. Une vigilance sur les sites voisins en cas d’hébergement mutualisé. Si plusieurs sites partagent un même compte d’hébergement, la sécurité de l’un dépend en partie de celle des autres.

Besoin d’y voir clair sur la sécurité de votre site ?

Un site WordPress qui tourne sans accroc, ce n’est pas un coup de chance : c’est le résultat d’une maintenance régulière et d’une vigilance de tous les instants. Si vous n’avez pas la certitude que votre site est correctement sauvegardé, à jour et protégé contre ce genre de scénario, mieux vaut vérifier maintenant plutôt qu’après un retour de vacances stressant.

Je propose un accompagnement de maintenance et de sécurisation pour les sites WordPress (et PrestaShop) des indépendants et petites entreprises : mise en place de sauvegardes externalisées, suivi des mises à jour, installation et configuration d’un plugin de sécurité, et intervention rapide en cas de problème.

Contactez-moi pour faire un point sur la sécurité de votre site — mieux vaut prévenir qu’avoir à nettoyer un site piraté sans sauvegarde saine.