WordPress piraté : plan d’action immédiat de sécurité

Un WordPress piraté ne ressemble presque jamais à ce qu’on imagine dans les films. Souvent, la première alerte arrive par un détail: une page d’accueil modifiée, des redirections bizarres, une hausse brutale de trafic vers des sites sans rapport, des emails envoyés depuis le compte d’un administrateur, ou encore un simple avertissement de Google Search Console. Dans ces moments-là, le réflexe le plus dangereux est de “régler vite fait” en installant un plugin ou en changeant un mot de passe sans comprendre ce qui a été compromis.

Un plan d’action immédiat, c’est surtout une façon de garder la tête froide: contenir l’incident, identifier la nature de l’intrusion, supprimer ce qui a été ajouté, puis reprendre un fonctionnement sain avec des garde-fous réalistes. Voici un déroulé concret, pensé pour des cas fréquents et pour les contraintes du terrain.

Arrêter la fuite sans casser tout le site

La première minute compte. Si le site est compromis, il peut servir à distribuer du spam, rediriger vers de la fraude, ou être utilisé comme tremplin vers d’autres cibles. Mais couper “brutalement” peut aussi vous priver de preuves ou déstabiliser des systèmes dont vous auriez besoin pour analyser.

L’objectif est simple: contenir. En pratique, selon votre hébergement et la complexité du site, vous avez plusieurs options. La plupart du temps, il vaut mieux mettre le site en mode maintenance et limiter l’accès à l’administration, plutôt que de supprimer tout accès.

Ce que je fais généralement en premier, c’est:

• vérifier si le compte administrateur semble encore utilisable, ou s’il y a des signes d’emprise (nouveaux utilisateurs, nouveaux rôles, plugin fraîchement installés),
• vérifier si le serveur répond toujours comme d’habitude, ou si des erreurs et des redirections indiquent une modification active,
• prendre des notes: heures, symptômes, URL concernées, captures rapides si possible (pages modifiées, code injecté visible).

Si vous avez la possibilité, activez un mode maintenance via l’hébergement ou via le fichier dédié, et bloquez les accès externes à l’admin. L’intérêt, c’est de ralentir ce que l’attaquant fait encore, tout en évitant de détruire la matière à analyser.

Faire l’inventaire rapide des signaux d’intrusion

Avant de supprimer quoi que ce soit, prenez le temps de repérer ce qui a été modifié. Sur WordPress, les intrusions suivent souvent des schémas répétitifs: ajout de code dans un thème ou un plugin, altération de fichiers core, création d’utilisateurs, modification de tâches planifiées, ou scripts malveillants via des uploads.

Un premier scan “raisonné” vous fait gagner énormément de temps. Regardez:

1) Les utilisateurs: nouveaux comptes, rôles inattendus, tentatives de connexion depuis des pays inconnus si votre hébergeur les affiche.

2) Les plugins et thèmes: toute installation récente, toute mise à jour suivie d’un changement de comportement, et surtout les plugins dont vous n’avez pas l’historique.

3) Les fichiers: présence de code dans des emplacements atypiques. Les attaquants adorent glisser du code dans des fichiers qui ne devraient pas changer. Par exemple, un fichier du thème qui n’a rien à voir avec le rendu peut contenir des fonctions qui exécutent du contenu externe.

4) Les redirections et injections: parfois, le site “est” propre côté admin mais une page injecte une redirection via un script dans le header ou dans un modèle de page.

5) La base de données: tables qui contiennent du code injecté, options WP modifiées, ou des champs qui déclenchent des comportements.

Dans l’urgence, vous n’allez pas tout parcourir à la main. L’approche efficace consiste à combiner l’observation (ce que vous voyez) et l’examen des points d’entrée les plus plausibles.

Préserver les preuves avant d’agir

Je sais, c’est tentant de “nettoyer maintenant”. Pourtant, si vous avez la moindre chance de comprendre le vecteur initial, quelques captures et sauvegardes du contexte valent de l’or. Ce n’est pas pour la police, c’est pour vous.

Si votre hébergement le permet, conservez:

• une copie des fichiers suspectés (au minimum les fichiers de thème et de plugin modifiés),
• un dump de la base de données ou, à défaut, une export partiel des tables qui ont changé,
• des logs bruts (accès web, tentatives de connexion, erreurs PHP, parfois logs applicatifs).

Même si vous finissez par tout restaurer, ces éléments vous aideront à répondre à une question cruciale: “comment ça a commencé ?” Sans cette réponse, vous risquez de nettoyer, puis de subir une seconde fois.

Plan immédiat en 5 étapes (contenir, diagnostiquer, éradiquer, restaurer, renforcer)

Voici un déroulé que vous pouvez réellement suivre pendant l’incident. Il ne remplace pas un audit complet, mais il structure l’urgence.

• Mettre le site en maintenance et limiter l’accès à l’administration (le temps de maîtriser les modifications et d’éviter la poursuite des actions).
• Récolter les indicateurs: utilisateurs ajoutés, plugins/thèmes récents, pages modifiées, redirections visibles, et tout code suspect dans les fichiers.
• Isoler le vecteur: identifier le point d’entrée probable (identifiants compromis, fichier injecté, plugin vulnérable, mauvaise configuration, script dans uploads).
• Nettoyer avec méthode: supprimer ce qui a été ajouté, restaurer les parties modifiées depuis des sources fiables, puis vérifier la base et les cron/tâches.
• Restaurer proprement et renforcer: mise à jour, rotation des mots de passe, durcissement d’accès, vérification du fonctionnement et surveillance sur plusieurs jours.

C’est volontairement “sérieux” sur la restauration, parce que beaucoup d’incidents échouent au moment du retour en ligne.

Diagnostiquer sans se tromper de cible

Le diagnostic, c’est ce qui différencie une reprise rapide d’une reprise fragile. Sur WordPress, l’intrus peut agir à plusieurs niveaux, et si vous éliminez un symptôme mais pas la cause, le comportement revient.

Le cas le plus fréquent: identifiants compromis

Quand les identifiants ont fuité, l’attaquant essaie souvent de:

• créer un utilisateur admin ou éditeur,
• installer un plugin “utile” pour lui (par exemple pour créer des redirections),
• modifier un thème pour injecter du code à chaque chargement.

Dans ce scénario, le nettoyage doit inclure la rotation de tous les secrets et la vérification de l’origine. Si vous aviez un mot de passe faible ou réutilisé, le risque est que l’attaque revienne si vous ne coupez pas l’accès initial.

Un signal fréquent est la présence d’un utilisateur “créé récemment”, ou de tentatives de connexion répétées même après vos changements.

Le cas “thème ou plugin infecté”

Parfois, le site semble “vivant”, les pages affichent du contenu, mais derrière il y a une injection. Les attaquants préfèrent des emplacements qui s’exécutent au chargement, par exemple dans des fonctions du thème, ou dans des fichiers du plugin.

Une règle simple m’aide: si un fichier PHP contient du code qui ne ressemble pas à la logique du thème, ou s’il charge du contenu distant, ou s’il utilise des fonctions de téléchargement, d’exécution de code ou de manipulation de fichiers, il faut le considérer suspect jusqu’à preuve du contraire.

Dans l’urgence, la meilleure stratégie consiste à restaurer les thèmes et plugins depuis leurs sources d’origine (ou depuis une sauvegarde fiable), plutôt que d’essayer de “corriger” au hasard.

Le cas “base de données modifiée”

La base peut contenir des options modifiées, des schedules, ou des contenus injectés. Les patterns typiques https://gardewp.fr/securite-wordpress/ existent, mais vous ne voulez pas les deviner.

Si vous avez des redirections qui ne correspondent pas à un changement de fichier visible, la base de données devient prioritaire. Et si vous voyez des contenus injectés dans des pages, dans des champs de widgets ou des options, il faut traiter la base comme un élément compromis, au minimum en partie.

Éradiquer proprement: restaurer depuis le fiable, pas depuis le “presque”

La partie la plus délicate, c’est le nettoyage. Sur WordPress, il y a un piège psychologique: on croit que “si le site se charge, c’est réglé”. Or les injections peuvent rester dormantes, ou ne toucher que certaines pages et certaines conditions.

Le nettoyage efficace repose sur deux choix:

• soit vous savez exactement quel fichier est compromis et vous pouvez le remplacer proprement,
• soit vous restaurez l’ensemble depuis une sauvegarde connue saine.

En pratique, quand on est en urgence et que le niveau de confiance est incertain, je préfère la restauration. Elle est plus longue, mais souvent plus sûre.

Contrôles concrets à faire pendant le nettoyage

Sans transformer ça en une checklist interminable, je m’assure que:

• les thèmes et plugins installés récemment sont désinstallés, sauf ceux que vous jugez légitimes,
• les versions de WordPress et PHP sont compatibles et à jour,
• les scripts dans les fichiers de thème ne contiennent pas de charges externes,
• les tâches planifiées (cron) ne contiennent pas de commandes inutiles ou inconnues,
• les comptes administrateurs ont tous une authentification solide et des mots de passe uniques.

Si vous avez accès aux fichiers, examinez particulièrement les emplacements où des injections peuvent se cacher: fichiers “librairies” du thème, templates, fichiers PHP récemment modifiés, et répertoires d’upload où des fichiers atypiques peuvent apparaître.

Restaurer le service: retour en ligne avec prudence

Une restauration propre n’est pas juste “repasser la maintenance à off”. Il faut vérifier que:

• le site ne redirige plus vers des domaines suspects,
• les pages sensibles (accueil, pages de vente, formulaires, pages d’authentification) ne contiennent plus d’injections,
• les formulaires n’envoient plus des contenus malveillants,
• la navigation n’affiche pas de scripts additionnels.

J’ai déjà vu des cas où le front affichait “presque” normal, mais où le code injection restait actif sur une seule page, donc non visible tant qu’on ne testait pas la bonne URL.

Le bon réflexe consiste à tester depuis plusieurs navigateurs ou au moins avec un profil “propre”, et à vérifier le rendu du header et du footer, là où les injections se dissimulent souvent.

Renforcer après l’incident: éviter le second épisode

Après un piratage, la priorité n’est pas uniquement de “mettre à jour”. La priorité est de rendre l’attaque plus difficile et surtout de réduire le nombre d’accès qui peuvent être utilisés.

La sécurité WordPress ne tient pas sur un seul verrou. Elle tient sur une combinaison de contrôles: accès, mises à jour, limitation des permissions, surveillance, et hygiène applicative.

Rotation et durcissement des accès

Commencez par les comptes. Même si vous retrouvez votre administration, considérez que les identifiants peuvent rester compromis. Changez:

• le mot de passe de tous les comptes à privilèges,
• les clés liées à WordPress (les constantes de configuration si vous les utilisez),
• et révoquez les sessions si votre configuration le permet.

Ensuite, activez une couche d’authentification supplémentaire si ce n’est pas déjà fait. L’authentification à deux facteurs réduit le risque d’une seconde intrusion via identifiants volés.

J’ai vu des cas où le site avait été “nettoyé” une fois, puis retombait parce que le propriétaire avait changé le mot de passe, mais pas la cause du vol (phishing, réutilisation, ordinateur compromis). Donc, même si vous sécurisez techniquement, vérifiez aussi le côté humain.

Mettre à jour sans casser

Mettre à jour WordPress et les plugins, c’est nécessaire, mais il faut le faire avec méthode. Une mise à jour “pendant l’incident” peut casser une partie fonctionnelle et vous gêner pour diagnostiquer, mais une mise à jour après nettoyage évite de ré-exploiter une faille connue.

Le bon équilibre consiste à:

• mettre à jour WordPress,
• mettre à jour les plugins encore maintenus,
• supprimer les plugins inutiles ou obsolètes,
• remplacer les thèmes abandonnés.

Si votre site dépend d’un plugin rarement mis à jour, le risque est plus élevé. Le trade-off est clair: soit vous acceptez le risque en attendant un remplacement, soit vous migrez plus tôt.

Réduire la surface d’attaque

Beaucoup de sites restent vulnérables parce que l’environnement est trop permissif. Sans entrer dans la configuration serveur au cas par cas, les principes que j’applique sont:

• limiter les permissions sur les fichiers et les répertoires,
• éviter les accès admin exposés sans contrôles,
• restreindre l’upload si ce n’est pas nécessaire,
• surveiller les créations d’utilisateurs.

On peut avoir un WordPress parfaitement patché et être malgré tout exposé à cause d’un accès admin sans protection supplémentaire, ou d’une mauvaise hygiène côté droits.

Surveiller les jours qui suivent: la sécurité ne s’arrête pas au nettoyage

C’est une erreur classique de se dire que “c’est bon” après la restauration. Souvent, l’attaquant a laissé une porte dérobée, ou a simplement testé la résistance du site. Les jours suivants servent à vérifier que l’incident ne réapparaît pas.

Concrètement, je recommande:

• surveiller les logs d’accès et les erreurs PHP,
• surveiller la création de nouveaux utilisateurs,
• vérifier régulièrement que les plugins et thèmes n’ont pas changé,
• et garder un œil sur la Search Console ou sur tout système de notification.

Le monitoring doit être pragmatique. Vous n’avez pas besoin de passer vos journées dessus. Il faut des alertes pertinentes et un rythme de vérification.

Définir le vecteur pour ne pas recommencer

Le point le plus sous-estimé après un piratage, c’est l’enquête sur la cause initiale. Sans ça, on “corrige les dégâts” mais pas la brèche.

Pour trouver le vecteur, je regarde trois catégories:

• l’accès: quels comptes ont été utilisés, depuis quelle période, avec quelles erreurs ou quels patterns,
• l’application: quels composants étaient obsolètes, quels plugins posaient problème, quels fichiers ont été modifiés en premier,
• l’environnement: exposition réseau, configuration du serveur, règles de pare-feu, et pratiques d’hébergement.

Parfois, la cause est évidente: une mise à jour oubliée. Parfois, c’est plus subtil: un plugin non maintenu, un formulaire mal protégé, ou une bibliothèque incluse par un thème.

Un mot sur les outils et la “fausse tranquillité”

On voit souvent des recommandations qui consistent à “installer un scanner, puis rebooter”. Les outils peuvent aider, mais ils ne remplacent pas la logique de restauration et de vérification.

Un scanner peut détecter des signatures connues, mais il peut rater une variante. Et un site peut être “désinfecté” sur un aspect, tout en gardant une modification ailleurs.

Mon approche préférée consiste à combiner l’outil avec une méthode: observer, repérer ce qui a été modifié, restaurer ce qui doit l’être, puis vérifier le comportement réel. C’est plus fiable que la confiance aveugle dans un résultat.

Exemples vécus, pour éviter les erreurs classiques

Sur plusieurs incidents, j’ai vu des schémas récurrents.

• Dans un cas, le site semblait normal après nettoyage, mais un sous-domaine était toujours redirigé. La récupération s’était concentrée sur le domaine principal. Résultat, l’attaque avait un point d’entrée ailleurs.
• Dans un autre cas, l’injection se faisait via un fichier de thème, remplacé par le bon fichier, mais les options de la base avaient conservé des paramètres malveillants. Le site affichait un contenu propre, mais exécutait un comportement caché sur des pages spécifiques.
• Le plus frustrant: une restauration “depuis la dernière sauvegarde” qui n’était pas saine. La sauvegarde était trop récente, l’attaquant avait déjà modifié la base avant la copie. On a donc restauré le problème.

Ces expériences m’ont appris une règle simple: quand la confiance dans la sauvegarde n’est pas totale, mieux vaut reconstruire depuis des sources fiables et comparer ce qui a changé.

Ce que j’ajoute systématiquement à mon plan “après incident”

Une fois le site stable, je reviens au socle. Le but est que le prochain épisode ne démarre pas au même endroit.

Je privilégie trois axes: réduire la probabilité d’entrée, limiter l’impact si elle se produit, et augmenter la visibilité.

• Réduire la probabilité, c’est renforcer les identifiants, supprimer les composants inutiles et patcher.
• Limiter l’impact, c’est appliquer le principe du moindre privilège et segmenter les accès.
• Augmenter la visibilité, c’est activer des alertes sur les changements, suivre les logs, et faire des contrôles réguliers.

Si vous travaillez en équipe, le plan doit être connu et partagé. Un incident géré par une personne seule est plus fragile, surtout quand il faut prendre des décisions rapides.

Mini-check de fin, avant de rouvrir “à fond”

Avant de relâcher le site à la production totale (et avant de réactiver toutes les tâches automatiques), je fais un contrôle final, court, mais concret.

• Vérifier l’état des comptes: pas de nouveaux utilisateurs, rôles cohérents, mots de passe changés.
• Vérifier l’état des extensions: plugins et thèmes à jour, suppression des éléments récemment ajoutés.
• Vérifier les pages clés: accueil, pages de formulaire, pages de connexion, et quelques URL qui chargent le header.
• Vérifier les redirections et scripts: aucun comportement anormal vers des domaines inattendus.
• Vérifier les performances et erreurs: une injection laisse parfois des traces dans les erreurs PHP ou des comportements bizarres.

Une fois ces points passés, je relance la surveillance pendant au moins une semaine, parfois plus selon la sensibilité du site.

Quand faire appel à un spécialiste ?

Je n’aime pas l’argument “faites-vous aider” sans contexte. Dans l’urgence, il y a des actions que vous pouvez mener seul. Mais si vous observez un code très dispersé, une série de fichiers très nombreux, un doute fort sur la compromission serveur, ou un risque de données exposées, l’assistance d’un spécialiste peut éviter des mois de tâtonnement.

Le moment où je conseillerais de passer la main est quand vous n’arrivez pas à déterminer la cause après vos scans raisonnables, ou quand le site revient à un état compromis malgré une restauration “propre”. Là, le problème dépasse souvent un simple plugin corrompu.

Garder une cadence de sécurité WordPress réaliste

La sécurité n’est pas un sprint unique, c’est une routine. Le meilleur plan, celui qui tient sur la durée, se résume à des gestes simples et répétables: mises à jour, suppression du superflu, contrôle des accès, et vérification régulière.

Après un piratage, vous avez un avantage: l’équipe et vous-même êtes déjà mobilisés. C’est le bon moment pour transformer l’urgence en méthode. Et c’est exactement ce que ce plan cherche à faire: vous rendre capable d’agir vite, sans improviser, puis de renforcer pour que l’histoire ne recommence pas.

Si vous me décrivez votre contexte (hébergeur, si vous avez accès aux logs, présence d’un utilisateur ajouté, redirections visibles, plugins récents), je peux vous aider à adapter la séquence à votre situation, avec des priorités plus précises.