Quand un hébergeur passe un site WordPress en mode secours après un signalement d'abus, le réflexe le plus dangereux est de "juste supprimer les fichiers bizarres" et de remettre le site en ligne. En Août 2026, nous avons repris en urgence le site institutionnel d'OSI dans cet exact contexte : des webshells PHP, un cloaking SEO destiné aux robots, des comptes administrateurs fantômes et une persistance assez profonde pour survivre à un nettoyage cosmétique. Ce n'était plus une alerte antivirus isolée, c'était une prise de contrôle complète du CMS. Nous avons choisi de documenter la méthode ici, sans folklore forensique inutile, pour les équipes marketing et techniques qui doivent décider vite : isoler, prouver, reconstruire, puis durcir. Le coût d'une mauvaise restauration se paie deux fois : une seconde infection, puis une perte de confiance de la part de Google et du client.
Si vous cherchez le playbook multi-CMS de première réponse, notre article comment gérer un site web piraté reste le bon point d'entrée. Ici, nous descendons dans le cas WordPress concret, de la corrélation CVE jusqu'à la reconstruction sur une infrastructure dédiée. Cette trajectoire nourrit aussi notre offre de dépannage de site hacké : même logique, périmètre commercial clair, sans improvisation sur un arbre encore contaminé. En tant qu'agence WordPress, nous préférons une baseline saine à un site "nettoyé" qui se fait réinfecter en 48 heures.
Comment un WordPress se fait pirater
La plupart des incidents que nous traitons ne commencent pas par un génie du mal. Ils commencent par une surface d'attaque oubliée. Un plugin de sauvegarde ou de migration exposé, une version de WordPress Core non patchée, un mu-plugin d'hébergeur qui a désactivé les mises à jour automatiques, et le serveur reste ouvert pendant des semaines. Sur OSI, le scénario le plus plausible pour la porte d'entrée initiale est une faille critique du plugin WPvivid Backup & Migration (CVE-2026-1357) : upload de fichier non authentifié menant à une exécution de code à distance. La seconde escalade a été prouvée dans les logs via une chaîne d'exploitation du Core WordPress (famille dite wp2shell sur les versions 7.0.0 concernées), suffisante pour créer des administrateurs et installer des plugins malveillants.
Il existe une multitude d'autres vecteurs classiques : le facteur humain, les mots de passes non sécurisés, les configurations serveurs approximatives, les thèmes préfaits et leurs packs d'extensions embarquées. Ces derniers sont rarement mis à jour, parfois livrés en version crackée ou nulled. Ces builds tirent des mises à jour depuis des miroirs douteux, désactivent les contrôles de licence et élargissent la surface d'infection même quand ils n'ont pas servi de porte d'entrée le jour J. Ajoutez des permissions trop permissives sur wp-content/uploads et vous obtenez le terrain idéal pour un drop massif de shells. Le message n'est pas "WordPress est dangereux" : c'est "WordPress sans hygiène de patch et sans licences officielles devient une porte ouverte". Chez rou9e, nous exigeons des plugins premium sous licence officielle, des mises à jour suivies, et nous retirons sans regret les briques inutiles ou abandonnées.
Les signes concrets d'un site WordPress sous contrôle attaquant
Un site WordPress pirate ne se résume pas à une page défacée. Les indicateurs utiles sont plus techniques, et souvent invisibles pour un visiteur humain. Sur l'incident OSI, nous avons notamment documenté une quinzaine de comptes administrateurs WordPress créés par l'attaquant, plusieurs milliers de fichiers .htaccess de persistance déposés en masse, des webshells nichés sous des chemins d'images improbables, et des altérations du bootstrap WordPress destinées au cloaking SEO. Le cloaking affichait du spam e-commerce japonais aux crawlers tout en servant le site légitime aux navigateurs classiques : excellent pour brûler la réputation du domaine sans alerter immédiatement le client. Autres signaux fréquents : plugins inconnus activés, thèmes modifiés, fichiers PHP déguisés en médias, ralentissements, alertes Wordfence ou Search Console, et un historique d'accès qui montre des sessions admin depuis des infrastructures cloud jetables. Nous classons toujours les preuves avec un niveau de confiance : prouvé dans les logs, fortement inféré, ou simple hypothèse. Cette discipline évite de restaurer le mauvais snapshot ou de "nettoyer" un fichier légitime. Si vous voyez seulement la partie visible - redirection bizarre, pop-up, spam dans Google - partez du principe que la racine est plus profonde. Un malware WordPress moderne cherche la persistance, pas la démonstration. C'est précisément pour cela qu'un scan rapide suivi d'une remise en ligne est, dans la majorité des cas, une récidive programmée. Documentez d'abord, coupez ensuite l'accès public, puis seulement après lancez la reconstruction : l'ordre des opérations change le résultat.
Isoler le site et choisir une base saine avant tout nettoyage
La première décision n'est pas "quel antivirus lancer", c'est "comment arrêter l'hémorragie sans détruire les preuves". Nous isolons le www/ compromis, nous le renommons pour qu'il ne soit plus servi, et nous conservons un paquet forensique complet : fichiers, base de données, logs applicatifs, etc. Ensuite vient le choix de la base de restauration, restaurer le snapshot le plus frais est souvent la pire idée : vous remettez en production les backdoors ou une version infectable. Nous comparons ensuite le clean vs le compromis : diffs fichiers, diffs SQL, revue des administrateurs, des active_plugins, des options anormales. Les logs access et PHP permettent de dater les premières écritures de shells, les activations de plugins malveillants et les sessions d'escalade. Pendant ce temps, le site public peut rester en maintenance : mieux vaut une page honnête qu'un domaine qui continue à servir du spam aux robots. Cette phase est aussi celle où l'hébergement web et l'infogérance comptent : accès SSH maîtrisés, pare-feu, sauvegardes hors ligne, journalisation exploitable. Sans ces briques, vous naviguez à vue. Notre règle maison : ne jamais remettre en ligne un arbre quarantaine "un peu nettoyé" ; on reconstruit depuis une baseline prouvée saine, puis on durcit avant le go-live.
Reconstruction et durcissement : le cas OSI
Pour OSI, la reconstruction a suivi une séquence courte et non négociable. Rebuild depuis la baseline saine, montée de version WordPress et PHP (PHP 8.4 en production), mise à jour des plugins et thèmes légitimes, suppression du vecteur d'entrée (WPvivid retiré), désactivation du mu-plugin qui bloquait les auto-updates, rotation des salts et des mots de passe, désactivation de l'éditeur de fichiers, blocage XML-RPC, Wordfence et contrôles anti brute-force, cache de pages, durcissement des permissions, et bascule vers un environnement dédié sous Dokploy. Le détail de notre stack Docker / Dokploy est décrit dans notre retour d'expérience migration serveur vers Dokploy : isolation par projet, TLS, Redis, sauvegardes avec rétention, contrôles d'edge sur les routes sensibles. Côté application, nous avons aussi réduit la surface : composants inutiles retirés, thème enfant propre, rescan des indicateurs de compromission sur l'arbre déployé avant ouverture publique. Le go-live a eu lieu début août 2026 après les gates de validation. Point important pour la suite commerciale du sujet : la reconstruction technique n'est qu'une moitié du travail. L'autre moitié, c'est la gouvernance - comptes nominatifs à privilèges minimaux, 2FA sur le back-office et les SaaS liés, SMTP externe dédié, rotation des secrets tiers, politique de mises à jour. Sans cela, le plus beau rebuild redevient une cible. Nous préférons le dire clairement aux clients : un dépannage sans durcissement est un pansement.
Un rapport forensics de 37 pages pour décider sans improviser
Au-delà du rebuild, nous avons livré à OSI un rapport d'investigation complet - 37 pages, loin du simple résumé exécutif. Son rôle n'est pas de faire joli en PDF : il sert de base de décision partagée entre direction, équipe technique et interlocuteurs externes. Le document fixe le périmètre, le niveau de sévérité, les responsabilités de chacun, décrit les preuves trouvées et leurs limites de couverture. Il détaille surtout la méthodologie (chasse IOC, diffs fichiers/SQL, revue des logs, corrélation CVE), pose une timeline détaillée et datée, liste les indicateurs de compromission exploitables, explique les causes racines avec un niveau de confiance, évalue l'exfiltration (ce qui a été prouvé et ce qui ne l'a pas été). Enfin, il retrace containment / reconstruction / durcissement, sépare clairement les résolutions déjà livrées des actions encore à la charge du client, et s'achève sur un glossaire pour que non-spécialistes et spécialistes parlent le même langage. En substance : prouver ce qui s'est passé, éviter de restaurer le mauvais arbre, prioriser les correctifs, et laisser une trace auditable si l'incident doit être relu dans six mois.
Ce qu'il faut verrouiller après un nettoyage WordPress réussi
Une fois le site WordPress remis en ligne, le vrai indicateur de succès n'est pas *plus d'alerte aujourd'hui*, mais *l'attaquant ne peut plus reprendre la main*. Notre checklist post-incident tient en quelques blocs :
- Rapports : livrables forensics écrits (périmètre, preuves, timeline, causes, exfiltration, actions client) pour piloter la suite sans perte de contexte.
- Logiciel : core, thèmes et plugins à jour, licences officielles uniquement, thèmes préfaits audités pour leurs extensions embarquées, extensions abandonnées désinstallées.
- Identités : comptes staff individuels, plus de compte admin partagé, sessions invalidées, 2FA obligatoire.
- Plateforme : sauvegardes testées hors site, surveillance de disponibilité et d'intégrité, WAF / rate-limit sur login et REST, permissions fichiers strictes, plus d'outils de migration exposés en production sans nécessité.
- Contenu et SEO : contrôle Search Console, purge du cloaking résiduel, surveillance des indexations suspectes pendant plusieurs semaines.
- Organisation : qui patch, qui valide, qui est réveillé à 2 h du matin.
