Lorsque vous découvrez qu’un site WordPress a été compromis, la tentation est de tout faire en même temps : supprimer les fichiers malveillants, changer tous les mots de passe, lancer un scanner, restaurer une sauvegarde, appeler l’hébergeur. Réalisées dans le mauvais ordre, ces actions peuvent détruire les preuves dont vous avez besoin pour trouver le point d’entrée, laisser l’attaquant toujours présent sur le serveur et rendre la récupération plus difficile qu’elle n’aurait dû l’être. Cet article décrit l’ordre des opérations que nous suivons dans les 24 premières heures après une compromission WordPress confirmée.
Heure 0 : confirmez la compromission
Avant de déclencher une réponse d’urgence, assurez-vous qu’il y a bien une compromission. Certains symptômes ont des explications anodines. Un nouvel utilisateur administrateur peut être un collègue qui a oublié de le mentionner. Un fichier de thème modifié peut être un changement en attente d’un développeur. Un avertissement dans une extension de sécurité peut être un faux positif.
Vérifiez d’abord les signaux les plus forts. Des fichiers à la racine du document qui ne devraient pas s’y trouver. Des URL indexées dans la Search Console qui ne correspondent à rien sur votre site. Des fichiers du cœur de WordPress modifiés. Des connexions sortantes vers des destinations suspectes. Des avertissements du navigateur sur l’URL. Dès que l’un d’eux est confirmé, vous avez un incident.
Heure 1 : prenez un instantané forensique
C’est l’étape que la plupart des gens sautent et regrettent le plus souvent par la suite. Avant de changer quoi que ce soit, prenez une sauvegarde complète de l’état compromis actuel. Fichiers, base de données, tout. Stockez-la hors site, à un endroit qui ne sera pas touché. C’est votre instantané forensique. Sans lui, vous ne pourrez pas retracer comment l’attaquant est entré, et sans cela, la même attaque se reproduira.
L’instantané n’est pas destiné à la restauration. Il sert à l’analyse. Gardez-le séparé de vos sauvegardes propres.
Heure 2 : communiquez, mais pas encore publiquement
Informez les personnes qui doivent savoir. L’équipe sécurité de votre hébergeur, surtout s’il gère une infrastructure mutualisée. Votre développeur ou votre agence. En interne, toute personne disposant d’un accès administrateur. Les clients et le public peuvent attendre que vous ayez des faits et une remédiation claire en cours. La communication publique pendant la phase de chaos est souvent erronée et crée plus de travail qu’elle n’en résout.
Heure 3 : contenez les dégâts
Arrêtez l’hémorragie sans effacer les preuves. Si l’attaquant a visiblement défiguré des pages ou diffuse des logiciels malveillants, mettez le site temporairement hors ligne. La plupart des hébergeurs proposent un mode maintenance ou une page « bientôt disponible » que l’on peut activer en quelques secondes. Cela protège les visiteurs sans écraser le moindre fichier.
Si certaines pages précises sont compromises mais que le reste du site fonctionne, vous pouvez les contourner avec des redirections ou des blocages temporaires au niveau de l’hébergeur. Évitez de modifier des fichiers à moins d’y être contraint.
Heures 4 à 6 : faites tourner tous les identifiants
Partez du principe que tout identifiant que l’attaquant a pu toucher est compromis. Changez-les tous :
- Les mots de passe administrateur de WordPress.
- Le mot de passe du panneau de contrôle de l’hébergement.
- Les identifiants SFTP et SSH.
- Le mot de passe de la base de données, puis mettez à jour wp-config.php avec la nouvelle valeur via la console de l’hébergeur plutôt que sur le site en ligne.
- Toute clé d’API stockée dans des extensions pour l’e-mail, le paiement, l’analytique ou d’autres services.
- Les salts et les clés de WordPress dans wp-config.php.
Faire tourner les salts et les clés invalide toutes les sessions WordPress existantes, ce qui vous expulse, vous comme tout attaquant. C’est essentiel. Sans cela, un attaquant ayant capturé un cookie de session peut conserver l’accès même après le changement de tous les mots de passe.
Heures 6 à 12 : identifiez le point d’entrée
Utilisez maintenant l’instantané forensique pour comprendre comment l’attaquant est entré. Examinez les modifications récentes de fichiers à la racine du document. Examinez les journaux d’accès de l’hébergement à la recherche de requêtes POST inhabituelles vers wp-admin/admin-ajax.php, wp-login.php, xmlrpc.php ou des endpoints spécifiques à des extensions. Examinez la liste des extensions à la recherche de toute extension présentant une vulnérabilité connue pour la version installée.
Dans l’étude de cas de Sydney que nous avons évoquée dans des articles précédents, le point d’entrée était presque certainement une extension de gestionnaire de fichiers obsolète, avec un long historique de vulnérabilités d’exécution de code à distance. L’identifier a fait la différence entre traiter le symptôme et traiter la cause.
Sans trouver le point d’entrée, l’attaquant sera de retour en quelques jours, souvent en quelques heures.
Heures 12 à 18 : nettoyez méthodiquement
Une fois le point d’entrée connu et l’instantané forensique préservé, commencez le nettoyage. Supprimez tous les fichiers malveillants. Comparez les fichiers du cœur de WordPress aux versions officielles et remplacez tout ce qui a été modifié. Vérifiez les thèmes et les extensions de la même manière. Auditez les utilisateurs et supprimez tout compte inconnu. Passez en revue le contenu des articles à la recherche de liens ou de scripts injectés. Examinez la base de données à la recherche de clés d’options de logiciels malveillants connues et d’entrées suspectes dans wp_options.
Certaines compromissions sont assez étendues pour que la bonne réponse soit de restaurer une sauvegarde propre antérieure à l’incident et de ne réappliquer que les changements de contenu vérifiés depuis. D’autres sont assez circonscrites pour qu’un nettoyage chirurgical soit plus rapide.
Heures 18 à 24 : refermez la porte
Corrigez la vulnérabilité qui a laissé entrer l’attaquant. Si c’était une extension obsolète, mettez-la à jour ou supprimez-la. Si c’était un mot de passe faible, la rotation l’a déjà réglé, mais activez la 2FA pour que cela ne puisse plus se reproduire. Si c’était un cookie de session volé, vous avez déjà fait tourner les clés et les salts. Si c’était un e-mail de phishing ayant capturé un identifiant administrateur, formez l’équipe et auditez l’activité de connexion à la recherche d’autres comptes compromis.
Appliquez un durcissement supplémentaire qui aurait empêché l’attaque :
- Bloquez l’exécution de PHP dans le dossier des téléversements.
- Restreignez l’accès à xmlrpc.php.
- Activez des limites de tentatives de connexion et la 2FA sur chaque compte administrateur.
- Passez à une extension de sécurité qui surveille l’apparition de nouveaux fichiers à des emplacements inattendus.
Les 48 heures suivantes
Une fois le site nettoyé, le travail n’est pas terminé. Lancez une nouvelle analyse de logiciels malveillants avec au moins deux outils réputés pour recouper les résultats. Soumettez une demande de réexamen dans la Google Search Console si une action manuelle a été appliquée. Communiquez avec les clients si des données ont potentiellement été exposées. Documentez ce qui s’est passé, la chronologie, le point d’entrée et les changements effectués. Ce document est destiné à votre équipe et à tout audit futur.
Besoin d’un coup de main ?
Si votre site WordPress est actuellement compromis ou si vous le soupçonnez, une réponse d’urgence aux incidents est disponible. Prenez contact immédiatement et nous vous guiderons à travers les étapes ci-dessus en temps réel : plus la réponse est précoce, plus les dégâts sont limités. Parlez-en à l’équipe de Defyn.
Most Read
-
Le coût réel de négliger la maintenance de WordPress en 2026
-
SEO local pour les banlieues de Sydney : comment gagner une place dans le pack local
-
À quoi ressemble vraiment le SEO local en 2026 pour une entreprise de Sydney
-
La liste de contrôle d’audit SEO technique que toute entreprise de Sydney devrait exécuter



