Restaurer un site WordPress après une intrusion, ce n’est pas juste “remettre les fichiers” et “relancer”. On parle souvent de désinfection WordPress au moment où l’on nettoie le code, les utilisateurs et la base de données. Mais, dans les faits, la partie la plus sournoise commence après la restauration: vérifier que tout fonctionne de façon cohérente avec l’environnement actuel, sans recontaminer le site, et sans casser des éléments qui n’ont pas été touchés par l’incident.
J’ai vu des sites “déjà propres” qui redeviennent instables quelques jours plus tard, non pas parce que la désinfection était mauvaise, mais parce qu’un détail de compatibilité a été ignoré. Un plugin désactivé puis oublié. Une version de WordPress revenue en arrière avec une dépendance implicite. Un cache qui sert encore des pages injectées. Un certificat TLS renouvelé différemment, qui casse la logique de redirection. En clair, la restauration peut corriger l’attaque, mais elle peut aussi créer des écarts techniques, et ces écarts deviennent des failles d’exploitation ou des points de défaillance.
Ce guide est pensé pour une situation très concrète: vous avez restauré WordPress (fichiers, base, ou les deux). Maintenant vous devez valider la compatibilité, la cohérence et les comportements sensibles, afin d’éviter un retour en arrière involontaire.
Pourquoi la compatibilité devient un sujet de sécurité
La désinfection WordPress a un objectif simple: enlever les modifications malveillantes, rétablir une base saine, et couper les chemins d’exécution. La compatibilité, elle, traite la question suivante: “Le site restauré s’exécute-t-il correctement dans son environnement, avec ses dépendances réelles?”
Un site peut être propre sur le plan “fichiers et base”, tout en restant problématique:
- si une extension indispensable n’est pas compatible avec la version restaurée de WordPress, si un thème ou un build d’assets a été restauré en décalage avec son mécanisme de cache, si un outil de sécurité, un WAF, ou une règle de filtrage attend un format d’URLs différent, si la restauration a remis des tables ou des options partielles.
Dans ce genre de cas, la sécurité et la stabilité sont liées. Une erreur, une exception fatale, un plugin qui “re-télécharge” quelque chose, ou une boucle de redirection peuvent créer des fenêtres d’exploitation. Et même sans intention malveillante, un site cassé incite à faire des bricolages urgents, donc risqués.
Un exemple typique: après restauration, le site renvoie une page d’erreur 500 sur certaines pages. L’équipe corrige en réactivant manuellement “ce qui semblait lié”, sans revérifier les comptes administrateurs et les hooks. Deux jours après, on découvre un nouvel utilisateur créé via une tâche planifiée ou une fonctionnalité rétablie. Ce n’est pas forcément l’attaque d’origine qui revient, c’est souvent la continuité d’un mécanisme persistant, ou la réintroduction d’une partie de l’environnement qui n’était pas censée être active.
Comprendre ce que “restaurer” a réellement changé
Avant de tester la compatibilité, il faut clarifier ce qui a bougé. Sur un incident, on restaure rarement “tout pareil”. On restaure souvent:
- des fichiers provenant d’une sauvegarde plus ancienne, la base partiellement, ou en totalité, des uploads à une date différente, un export MySQL remis en arrière, avec des options et des meta associées.
Même si vous avez une stratégie propre, il existe presque toujours un décalage de calendrier. Ce décalage peut être de quelques heures. Il peut aussi être de plusieurs jours si la dernière sauvegarde exploitable était ancienne.
Ce point compte parce que la compatibilité n’est pas juste “ça s’affiche”. Elle concerne aussi le fonctionnement interne. Lorsqu’on réinstalle une base à partir d’un moment t, les tables contiennent des références à des choses qui peuvent ne plus exister côté fichiers ou côté configuration serveur. Un plugin peut être désactivé dans l’admin, mais encore présent dans la base. Un thème peut être en place en fichiers, mais son manifest d’assets absent. Un mode de cache peut servir du contenu qui ne correspond plus à l’état actuel.
La première étape de vérification, c’est donc d’établir un inventaire rapide de versions et d’éléments restaurés.
Valider les versions: WordPress, PHP, plugins, thèmes
La compatibilité commence par les bases. Si WordPress restauré est plus ancien que l’environnement serveur actuel, ou si PHP a été mis à jour pendant l’incident, vous risquez:
- des erreurs PHP fatales, des plugins qui ne chargent pas leurs fichiers, des comportements “silencieux” (un hook qui ne s’exécute pas, un champ qui ne se rend pas, des redirections en dehors des attentes).
Et l’inverse existe aussi: WordPress restauré plus récent que la configuration serveur, avec un plugin qui exige une extension PHP spécifique, par exemple une extension de cryptographie ou de compression.
Sans transformer cette vérification en audit exhaustif, je recommande de comparer trois choses sur le site restauré: 1) la version de WordPress réellement installée, 2) la version PHP côté serveur, 3) la liste des plugins et thèmes actifs après restauration.
Ce que vous cherchez n’est pas seulement “ça marche”. Vous cherchez aussi les écarts, car un écart peut expliquer une régression fonctionnelle qui, ensuite, pousse à des manipulations dangereuses.
Un mini test “fonctionnel” utile
Sur un site récemment restauré, je fais un test très simple, avant toute grande modification:
- connexion admin, chargement d’une page publique normale, accès au tableau de bord, envoi d’un formulaire de base (par exemple contact si le site en a un, ou un test de formulaire quelconque).
Si ces étapes échouent, ce n’est pas “juste une bug”. Ça indique une incompatibilité ou un élément manquant. Et dans un contexte d’intrusion, l’erreur doit être traitée comme un signal: soit un plugin réactivé n’est pas compatible, soit une restauration partielle a laissé un morceau de logique cassé, soit une règle de sécurité bloquant des URLs a changé depuis la restauration.
Vérifier la cohérence des fichiers de configuration
Ensuite, on passe aux fichiers qui pilotent le comportement. Dans un incident, il arrive que l’on restaure surtout l’application, et qu’on laisse en place des fichiers de configuration modifiés pendant l’attaque, ou une configuration différente côté serveur.
Je parle ici notamment de fichiers d’environnement et de configuration WordPress classiques, ou des équivalents selon votre hébergeur. L’enjeu n’est pas de “trouver un malware” dans chaque ligne. L’enjeu est de confirmer que ce que vous croyez avoir restauré est effectivement en vigueur.
Concrètement, recherchez les divergences entre:
- ce que la sauvegarde apportait, ce que l’hébergement applique aujourd’hui, les variables de configuration ajoutées pendant la phase de remédiation.
Un cas fréquent: la restauration remet un fichier .htaccess ou des règles de réécriture dans un état différent. Si le site fonctionne avant incident mais redirige mal après restauration, c’est souvent là que ça se joue. Et une redirection mal configurée peut exposer des endpoints inattendus, ou casser des protections déjà en place.
Même logique côté réglages PHP: si les modes ou limites changent, certains plugins se comportent différemment. Cela peut ne pas sembler “dangereux”, mais cela peut pousser un plugin de sécurité à réécrire des règles ou à modifier des headers, et donc créer des différences de surface d’attaque.
Recontrôler la désinfection WordPress après restauration, sans se contenter du “propre”
Il y a une tentation naturelle: “on a restauré, donc c’est bon”. En pratique, vous devez recontrôler. Mais plutôt que de refaire la désinfection complète comme si vous repreniez depuis zéro, vous pouvez faire une vérification orientée compatibilité et persistance.
Voici ce que je surveille en priorité après une restauration:
- la présence d’utilisateurs anormaux (rôles admin, auteurs, comptes nouvellement créés), des scripts ou tâches planifiées qui reviennent, des hooks ou fichiers ajoutés dans des emplacements peu habituels, des liens dans le contenu ou dans les options qui reviennent après un certain temps.
Le point clé est le suivant: si quelque chose reparaît après la restauration, vous avez soit un mécanisme persistant vivant dans la base ou dans le serveur, soit une réintroduction lors d’une étape ultérieure (réinstallation de plugins, réactivation d’un thème, import d’options, synchronisation).
Cette vérification redevient une question de compatibilité, car une étape de restauration “après” (par exemple un déploiement d’extensions) peut relancer un comportement qui avait été neutralisé.
Le piège du cache et des pages servies “à l’ancienne”
Quand un site a été compromis, il est très courant que du contenu injecté soit stocké quelque part. Parfois directement dans la base. Parfois dans le cache applicatif. Parfois via un cache serveur ou un CDN.
Après restauration, le test classique “je recharge la homepage” peut être trompeur. Si le cache sert une version ancienne, vous voyez encore l’injection, même si les fichiers restaurés sont propres. À l’inverse, si le cache sert une version propre, vous pourriez ne pas détecter une persistance sur des pages qui ne sont pas encore recalculées.
Donc, avant de conclure sur la désinfection WordPress, il faut:
- purger le cache WordPress si vous utilisez un plugin de cache, purger le cache serveur si vous en avez un (Varnish ou autre), invalider le cache CDN si vous passez par une distribution externe.
C’est aussi une question de compatibilité, car un plugin de cache peut être incompatible avec la version restaurée, et continuer à servir des contenus obsolètes, ou pire, produire des pages tronquées ou corrompues.
Sur un site que j’ai eu à traiter, le contenu injecté n’apparaissait plus en direct, mais persistait sur certaines pages paginées. Le cache applicatif était partiellement invalidé. Le diagnostic n’était pas “malware dans les fichiers”, c’était une invalidation qui ne couvrait pas toutes les routes.
Compatibilité entre la base restaurée et les plugins actifs
C’est souvent là que les surprises arrivent. La base contient des options, des post types, des meta, et des réglages d’extensions. Une restauration de la base sans aligner la version des plugins et des thèmes peut créer des incohérences.
Exemples concrets d’incompatibilités:
- un plugin d’optimisation d’images qui s’appuie sur une table ou une structure créée à une version plus récente, un builder de page qui s’attend à un format d’assets ou à un schéma de données particulier, un plugin de sécurité qui a enregistré des règles ou des paramètres qui ne correspondent plus au comportement de WordPress restauré.
Quand cela se produit, vous pouvez avoir:
- des pages qui se chargent en partie, des erreurs dans le journal, des scripts bloqués, des formulaires qui ne soumettent plus.
L’aspect sécurité intervient quand un plugin cesse de fonctionner mais continue à être “actif” d’un point de vue WordPress. Certains plugins modifient des filtres. Si ces filtres se comportent mal, vous pouvez avoir une surface d’attaque modifiée sans le savoir.
La bonne approche est pragmatique: réduire d’abord, stabiliser ensuite. En contexte d’incident, on ne “tente” pas tous les plugins. On réactive progressivement ce qui est indispensable, en surveillant la stabilité et les logs.
Une liste courte pour éviter les erreurs de séquençage
Voici un mini check que j’utilise lors d’une restauration, pour limiter les régressions et les surprises:
- Comparez la liste des plugins et thèmes actifs avant et après restauration, même si vous n’avez pas toutes les versions exactes. Désactivez temporairement les plugins non essentiels et vérifiez que le site fonctionne (pages clés, formulaires, recherche si elle existe). Réactivez ensuite un plugin à la fois, en surveillant le comportement pendant une courte fenêtre (quelques minutes à une heure selon l’usage). Purgez le cache à chaque changement si vous avez un plugin de cache, ou invalidez au moins les pages sensibles. Consultez les journaux (PHP et serveur) après chaque réactivation, car les erreurs répétées sont un signal d’incompatibilité.
C’est moins une question “théorique” qu’une discipline. Elle évite de réactiver un plugin problématique qui n’était pas le vecteur initial, mais qui devient la nouvelle cause d’instabilité.
Réexaminer les permissions et la configuration serveur
La compatibilité, ce https://gardewp.fr/nettoyage-malware-wordpress/ n’est pas seulement WordPress et ses extensions. C’est aussi la façon dont le serveur exécute le code.
Après une restauration, il arrive que les permissions de fichiers, le propriétaire, ou les droits d’écriture ne soient pas identiques à l’état attendu. Une désinfection WordPress peut inclure des suppressions et des rechargements, et donc créer des divergences.
Pourquoi c’est important? Parce que:
- un plugin peut échouer à écrire certains fichiers (uploads, cache, logs), des fichiers d’assets peuvent ne pas se générer, et surtout, des erreurs d’écriture peuvent pousser à des modifications manuelles du serveur, parfois trop permissives.
Du point de vue sécurité, je préfère une logique stricte: les répertoires nécessaires en écriture uniquement pour l’utilisateur approprié, pas pour tout le monde. Toute dérive dans les permissions mérite un contrôle, même si “ça marche”.
Côté serveur, surveillez aussi les règles qui bloquent ou autorisent des URLs. Si vous avez mis en place un filtrage pendant l’incident, il faut confirmer qu’il reste compatible avec l’état restauré. Sinon, vous risquez des comportements bizarres: des pages non accessibles, des boucles, des erreurs d’authentification, ou des endpoints de diagnostic qui restent ouverts parce que les règles n’ont pas été alignées.
Contrôler les redirections, les URLs canoniques et les changements de domaine
Un incident peut aussi s’accompagner de modifications indirectes: le site a changé d’IP, ou vous avez mis temporairement un domaine de staging. Vous pouvez avoir changé de protocole (HTTP vers HTTPS), ou modifié des règles d’accès.
Après restauration, c’est le moment de vérifier:
- le comportement des pages avec et sans www, la redirection vers HTTPS, les canoniques, surtout si vous avez un SEO plugin, la logique des URLs dans les contenus.
Pourquoi je l’inclus dans la compatibilité après désinfection? Parce qu’une mauvaise redirection peut exposer des endpoints inattendus. Et parce que les caches, les cookies et les tokens d’authentification sont sensibles aux différences d’URL. Un plugin d’authentification ou de sécurité peut considérer un domaine comme “étranger” et refuser ou modifier des mécanismes, ce qui devient à son tour une source de comportements non prévus.
Sur certains sites, j’ai vu un cas où la restauration avait réintroduit une config de redirection contradictoire, avec un plugin de sécurité qui imposait des règles supplémentaires. Résultat: l’admin continuait de charger, mais les appels AJAX échouaient, car les URLs cibles ne correspondaient pas. L’équipe pensait que tout allait bien, jusqu’au moment où le site a dû être mis à jour, et le déploiement a échoué.
Tester des points “sensibles” plutôt que tout le site
On pourrait tester chaque page, mais c’est rarement réaliste, surtout pour des sites avec des milliers d’articles. L’idée est de tester les points qui révèlent le plus de compatibilité et de persistance.
Les points que je vise en priorité après restauration:
- la page de connexion et la gestion de session, la création ou modification d’un brouillon (un petit test, pas une publication réelle), le comportement des pages dynamiques qui s’appuient sur des plugins (recherche, formulaires, checkout si e-commerce), le chargement des scripts et des styles (pour déceler des erreurs d’assets), les pages qui utilisent le mécanisme de thème le plus complexe (builder, shortcode, templates).
Ce type de test est utile parce que si un plugin est incompatible, il se manifestera souvent dans ces zones.
Et du côté sécurité, si une persistance existe, elle se manifestera parfois sous forme de nouveaux utilisateurs, d’erreurs répétées, ou de contenu injecté qui apparaît sur des pages précises.
Vérifier que les mécanismes de sécurité restent cohérents
Après désinfection, vous avez souvent mis ou ajusté des protections:
- un plugin de sécurité, une règle WAF, une limitation de tentatives de connexion, des scans programmés, des durcissements côté serveur.
La compatibilité, c’est vérifier que ces protections fonctionnent avec l’état restauré. Un plugin de sécurité peut par exemple interpréter différemment les logs selon une version de WordPress, ou échouer à appliquer des règles si certaines dépendances ne sont pas là.
Je préfère une approche: vérifier d’abord la logique de base (connexion admin, chargement d’assets, endpoints AJAX), puis vérifier les alertes de sécurité.
Une deuxième mini discipline m’aide:
- si vous voyez des alertes après restauration, évitez de les ignorer en bloc, si vous voyez des erreurs de plugin, évitez de les “corriger” en désactivant tout, si les protections bloquent quelque chose qui doit fonctionner, adaptez la règle à l’environnement, pas à l’instinct.
Une seconde liste de contrôle courte pour la phase de validation
- Contrôlez la connexion admin et la soumission d’un formulaire de test. Purgez caches applicatifs et caches externes, puis refaites les tests sur des pages connues pour bouger. Surveillez les journaux 30 à 60 minutes après la restauration, surtout après la réactivation de plugins. Vérifiez qu’aucune tâche planifiée inattendue n’a été créée, ou que des tâches connues n’ont pas changé de comportement. Confirmez que les protections de sécurité ne laissent pas passer des erreurs répétées (500, 403, boucles de redirection).
Cette liste n’est pas “universelle”. Elle est utile parce qu’elle oblige à vérifier la dynamique après restauration, pas seulement la staticité.
Quand la restauration n’est pas alignée: décider entre “re-restore” et “patch”
Parfois, la restauration est techniquement propre, mais incompatible avec le reste. Vous êtes alors face à un choix délicat: corriger dans l’environnement restauré ou recommencer la restauration avec une base plus cohérente.
Je tranche généralement avec trois critères: 1) Est-ce que les erreurs sont stables ou transitoires? 2) Les erreurs viennent-elles de plugins, de thème, ou de la configuration serveur? 3) Le niveau de risque associé à un contournement temporaire est-il acceptable?
Si les erreurs proviennent d’un plugin incompatible, désactiver ce plugin est souvent la stratégie la plus sûre, surtout juste après un incident. Si les erreurs viennent d’un décalage de version plus profond, et que la correction implique de réintroduire des modifications complexes, la stratégie “re-restore” avec une sauvegarde plus alignée peut être plus sûre.
Mais attention, “re-restore” n’est pas neutre. Refaire une restauration peut réintroduire un autre état compromis si les sauvegardes ne sont pas toutes saines. D’où l’importance de documenter ce que vous restaurez, à quelles dates, et comment vous vérifiez ensuite.
Signes d’alerte qui doivent déclencher une enquête ciblée
Une restauration réussie n’empêche pas une enquête. Elle réduit seulement les hypothèses plausibles. Les signes ci-dessous méritent une attention immédiate car ils indiquent souvent une persistance ou une incompatibilité qui s’aggrave.
Je les regroupe sans liste pour respecter la logique de lecture, mais voici les idées:
- apparition répétée de nouveaux comptes admin ou de rôles inattendus, retour d’un contenu modifié après purge de cache, erreurs répétées dans les logs qui pointent vers un fichier spécifique, tâches planifiées qui changent toutes seules, comportements différents entre navigateurs, ou entre connexions admin et visiteurs, redirections incohérentes qui n’existent pas avant restauration.
Dans ces cas, on ne “répare” pas au hasard. On recoupe: logs, historique de restauration, correspondance entre fichiers et options de base, et configuration serveur. La compatibilité peut expliquer les erreurs, mais l’intrusion peut aussi expliquer les changements imprévus.
Documenter ce que vous avez vérifié, même si vous êtes pressé
Après un incident, vous aurez probablement des demandes internes, parfois des clients, parfois un service juridique, parfois un RSSI. Ce n’est pas qu’une formalité. La documentation transforme votre restauration en processus reproductible.
Au minimum, je note:
- les versions de WordPress et PHP après restauration, la liste des plugins et thèmes actifs, au moment de la validation, les caches purgés et quand, les points fonctionnels testés, les incidents relevés dans les logs pendant une fenêtre de surveillance.
Cela permet ensuite de comparer si un problème revient. Et si un audit externe arrive, vous ne partez pas d’un récit flou. Vous partez de décisions et de faits.
Ce que j’attends d’un site “vraiment restauré”
Au-delà de la désinfection WordPress et de la compatibilité technique, un site restauré doit avoir un comportement clair:
- il charge sans erreurs significatives, les mécanismes d’authentification et de formulaires fonctionnent, les protections sont actives et compatibles, la surface d’attaque est réduite, et rien ne se re-modifie de façon autonome.
C’est cette dernière condition qui fait la différence entre “ça marche maintenant” et “c’est stabilisé”.
La stabilité vient souvent avec une période d’observation. Une fenêtre de 24 à 72 heures n’est pas excessive après un incident, selon le volume de trafic et la sensibilité du site. Si vous constatez des anomalies après cette période, vous n’êtes pas obligés de supposer une nouvelle attaque, mais vous devez recontrôler les mécanismes de persistance et les incompatibilités introduites par la restauration ou par les réactivations post-incident.
Dernier point pratique: séparer validation et déploiement
Quand tout semble OK, on veut souvent “remettre en ligne” et enchaîner avec le normal. Dans les faits, je recommande de garder une séparation nette entre:
- la phase de validation de la compatibilité, et la phase de déploiement final (réactivation complète, mises à jour, configuration de production).
Si vous changez trop de choses en même temps, vous ne saurez pas ce qui a causé une régression. Et en contexte d’intrusion, vous ne voulez pas perdre cette capacité à attribuer les causes.
Sur un site que j’ai accompagné, le retour en ligne a été fait trop tôt, juste après la désactivation du plugin qui cassait. Deux jours plus tard, il fallait remettre des optimisations marketing. Ces optimisations ont entraîné un rechargement d’assets et un plugin a réactivé un comportement indésirable. Le site n’était pas re-compromis, mais l’équipe a perdu des heures à trier ce qui relevait de la compatibilité, de la configuration, ou de la persistance.
Ce tri aurait été plus simple si la validation et le déploiement avaient été séparés.
Après restauration, la désinfection WordPress n’est pas terminée à la seconde où le site redevient accessible. Elle continue sous une forme plus technique: vérifier que l’environnement restauré est compatible, cohérent, et stable, et que rien ne se réintroduit par accident. Quand vous reliez ce contrôle à une discipline de tests ciblés et de surveillance courte, vous réduisez à la fois le risque de persistance et le risque de régression. Et c’est précisément ce double objectif qui fait la différence entre un retour en ligne rapide et un retour en ligne solide.