Quand on parle de “désinfection” WordPress, la tentation est souvent de foncer sur le nettoyage côté contenus, thèmes, extensions, ou sur une suppression de fichiers suspects. C’est parfois suffisant. Mais dans les cas où l’attaque a été profonde, ou quand on ne sait plus exactement ce qui a été modifié, la vérification de l’intégrité du noyau devient un geste très concret, presque mécanique. Elle répond à une question simple: est-ce que les fichiers “WordPress core” correspondent bien à ce que le projet a publié, ou est-ce qu’on a eu la main sur les entrailles ?
Dans ce qui suit, je vais détailler comment vérifier l’intégrité des fichiers du noyau pour réduire le risque de https://gardewp.fr/ “rattrapage incomplet”, avec des méthodes réalistes, celles qu’on utilise en intervention quand il faut aller vite tout en gardant un niveau de preuve acceptable.
Le bon réflexe : traiter le noyau comme une zone critique
Un site compromis ne se limite pas toujours à une extension piégée. Il arrive que l’attaquant réussisse à modifier des fichiers de base, parce que:
- les permissions étaient trop larges (uploads exécutables, dossiers en écriture ouverte, absence de durcissement), un compte admin a été pris (et l’édition de fichiers est devenue possible), un mécanisme d’upgrade a été détourné (fichiers remplacés, scripts ajoutés, logique altérée dans des fichiers PHP du core), ou, plus rarement, un malware a été déposé dans des chemins où il ne devrait jamais être.
Vérifier le noyau ne remplace pas le nettoyage malware WordPress au sens large, mais ça change la suite des actions. Si le core est propre, on peut concentrer l’enquête sur les extensions, le thème, les fichiers de configuration et les utilisateurs. Si le core est altéré, tout ce qu’on fait après doit être pensé pour éviter de “réinfecter” malgré nous.
Je me souviens d’un incident où la scan “classique” disait “aucune extension infectée”, et pourtant le site renvoyait des redirections au moment exact du chargement d’une page spécifique. Le diagnostic a basculé quand la vérification des checksums du noyau a montré un écart sur un petit nombre de fichiers. Le nettoyage des extensions avait servi à calmer les symptômes, pas à régler la cause.
Ce que signifie “vérifier l’intégrité” dans WordPress
WordPress core est distribué sous une forme attendue. Vérifier l’intégrité, c’est comparer ce que vous avez sur disque avec une référence fiable. En pratique, on vérifie:
Les fichiers présents sur votre serveur. Leur contenu exact (hash, checksum). Leur correspondance avec une version précise de WordPress.Cette précision est importante. Un site peut afficher une version “6.4.x” mais courir sur des fichiers qui ne correspondent pas exactement, par exemple après un upgrade interrompu, ou après un patch appliqué “à la main”. Le contrôle d’intégrité ne doit pas être approximatif, sinon il crée un faux sentiment de sécurité.
Autre point: certaines modifications sont légitimes. Installer une “traduction” n’altère pas le même périmètre que modifier un fichier PHP du core. Déployer une routine de maintenance peut ajouter des fichiers dans wp-content, mais pas dans les dossiers du noyau. Si vous voyez des écarts dans wp-includes ou wp-admin, la probabilité de modification malveillante augmente fortement, même si tout n’est pas forcément criminel (erreurs d’upgrade, manipulations manuelles, intégrations internes).
Préparer le terrain avant de lancer une vérification
Avant de lancer la vérification, l’approche la plus propre est celle qui limite les surprises. Vous voulez pouvoir prouver ce que vous avez fait, et vous assurer que vous pouvez revenir en arrière.
Prérequis concrets
Vérifier l’intégrité du noyau suppose, dans l’idéal, deux choses: un accès fiable aux fichiers et un moyen de comparer. Côté accès, l’intervention varie selon votre contexte (hébergement mutualisé, VPS, accès shell, présence de WP-CLI, restrictions de sécurité). Côté comparaison, il faut une référence cohérente: soit le téléchargement officiel de la version concernée, soit un outil qui gère cette logique pour vous.
Voici un pré-check simple, utile sur le terrain:
- Identifier la version exacte de WordPress utilisée sur le site (et, si c’est un multisite, vérifier la version du réseau). Vérifier les permissions des fichiers du core (et éviter de corriger en “aveugle” si vous ne savez pas ce qui a changé). Faire un backup complet des fichiers du core et, au minimum, des fichiers de configuration (sans jouer avec les bases tant que vous n’avez pas le contexte). Prévoir une fenêtre de maintenance si le site peut dépendre de fichiers temporairement déplacés. Si vous avez WP-CLI et un accès shell, décider dès le départ de la méthode principale de comparaison (sinon vous passerez votre temps à jongler).
Cette préparation évite le scénario classique: “je répare le core”, puis “je découvre que j’avais un problème de droits sur wp-content”, puis “je n’arrive plus à prouver ce qui était modifié”.
Méthode 1 : WP-CLI pour vérifier les checksums du core
Quand WP-CLI est disponible, c’est souvent la voie la plus rapide et la plus propre, parce qu’elle réduit le bricolage. L’idée est de demander à WP-CLI de comparer les checksums des fichiers du noyau contre la référence attendue.
Sur un serveur où WP-CLI fonctionne, vous utilisez typiquement la commande de vérification des checksums du core. Les commandes exactes peuvent varier selon la version de WP-CLI et la configuration, mais le principe reste le même: lancer une vérification “core verify” qui vous renvoie une liste de fichiers modifiés ou manquants.
Voici les commandes à garder en tête (à adapter à vos chemins et votre installation):
- wp core version wp core verify-checksums wp --info
La commande wp core version sert à verrouiller la cible, parce que vérifier une version différente ne ferait que produire des résultats inutilisables. wp core verify-checksums est la pièce centrale: elle vous dit quels fichiers ne correspondent pas.
Quand on obtient des écarts, on ne se précipite pas sur la suppression. On note, on corrèle avec la chronologie d’événements (dernier déploiement, dernière mise à jour, accès admin suspect). Ensuite, on choisit une stratégie: restauration du core, ou remplacement contrôlé des fichiers concernés.
Interpréter les résultats sans se raconter d’histoires
Un piège fréquent: considérer qu’un seul fichier modifié suffit à “tout est compromis”. En réalité, ça dépend. Si un fichier du core montre une différence, c’est un drapeau rouge, même si la différence est minime. Mais le niveau d’impact dépend de quel fichier et quelle nature de modification. Par exemple:
- un fichier central de chargement du plugin système, ou une inclusion globale, a plus de chances de contenir une charge malveillante, un fichier rarement utilisé peut être lié à une adaptation ou à un artefact d’upgrade raté, et parfois, une modification “non malveillante” existe, comme un patch temporaire appliqué par un dev.
Cela dit, sur un site qui a déjà été signalé comme “suspect” ou “injecté”, je traite tout écart du core comme une modification à risque jusqu’à preuve du contraire. Le coût d’une restauration propre est souvent plus faible que le coût d’une enquête qui se prolonge.
Méthode 2 : comparaison manuelle avec une archive officielle
Quand WP-CLI n’est pas disponible, ou si l’accès shell est trop contraint, on fait autrement. La méthode manuelle consiste à:
Télécharger l’archive de la version exacte de WordPress, Extraire le contenu du core attendu, Comparer fichier par fichier, idéalement via hash (SHA256 ou autre), Remplacer uniquement ce qui diffère.Cette approche demande un minimum d’outillage, mais elle a un avantage: elle ne dépend pas de la logique interne de WP-CLI. Elle se base sur une référence que vous contrôlez.
Le point clé : la version doit être exacte
Le téléchargement officiel dépend de la version. Si votre site est en 6.5.3, comparez avec 6.5.3, pas avec 6.5.2. Si vous comparez “à peu près”, vous allez confondre des différences normales de build avec des modifications malveillantes.
Si vous n’êtes pas sûr de la version, un bon réflexe est de vérifier la version affichée dans l’administration, puis de recouper avec les métadonnées accessibles (par exemple, le fichier principal de WordPress, la constante de version). Un doute sur la version transforme la comparaison en chasse au fantôme.
Comparer avec des hashes, pas seulement en taille ou en dates
Comparer par taille ou par timestamp ne suffit pas. Deux fichiers peuvent avoir la même taille et du code différent. Les hashes, eux, vous donnent un résultat fiable.
Sur un environnement Linux, on utilise généralement sha256sum. Sur un hébergement Windows, ou via outils web, les possibilités changent, mais l’idée reste identique: générer une empreinte cryptographique de vos fichiers core, et la comparer à celle des fichiers de l’archive officielle.
Le travail peut être long si vous comparez des centaines de fichiers, mais en pratique, vous pouvez cibler les chemins les plus sensibles (wp-includes, fichiers PHP de wp-admin). Et si vous voulez accélérer l’intervention, vous pouvez aussi commencer par les fichiers “entry points” de l’application, souvent ceux qui sont modifiés en premier.
Méthode 3 : restauration du core comme test de non-régression
Il y a un troisième scénario, que j’utilise quand l’objectif est de restaurer un site le plus vite possible, tout en gardant une rigueur minimale: restaurer le core depuis une source officielle, sans modifier wp-content, puis revalider.
Le principe est simple: si vous remplacez wp-admin et wp-includes par des versions propres, et que le site redevient fonctionnel sans redirections ou comportements bizarres, vous avez un indice fort que le core était impliqué.
Mais attention à un détail important: si l’attaque a aussi touché des fichiers dans wp-content, vous ne verrez rien “de plus” et vous risquez de laisser des portes ouvertes. C’est pour ça qu’une restauration du core doit s’accompagner ensuite d’un contrôle des extensions, des thèmes, et des utilisateurs, sinon vous ne faites qu’éteindre un incendie sans colmater la cause.
Je considère cette approche comme un test diagnostique et réparateur, pas comme un “grand nettoyage final” à elle seule.
Ce que la vérification du core ne résout pas automatiquement
Vérifier le noyau ne garantit pas que tout le site est propre. Le core est une partie, pas l’ensemble. Voici les zones qui échappent au contrôle core:
- wp-content/plugins et wp-content/themes: extensions et thèmes modifiés, ajouts de fichiers, charges dans des hooks. uploads: scripts déposés dans des formats “disguisés” ou des fichiers modifiés à partir d’un formulaire mal protégé. base de données: options WordPress, cron, utilisateurs, métadonnées, contenus injectés. configuration serveur: règles de PHP, htaccess malveillant, configuration webserver détournée. utilisateurs: un compte admin compromis peut réintroduire des modifications dans les jours qui suivent la restauration.
C’est pour ça que la vérification de l’intégrité du noyau est un pivot, pas une fin de mission. En pratique, elle sert de point d’orientation: “on corrige le core” ou “on se concentre ailleurs”.
Gestion des cas limites qui arrivent sur le terrain
Le site a des modifications “légitimes” du core
Certaines équipes modifient le core, soit pour un besoin temporaire, soit par habitude. Si c’est le cas, la vérification d’intégrité va forcément signaler des écarts.
La vraie question devient: ces modifications sont-elles documentées, nécessaires, et gérées autrement que par un patch permanent ? Dans la majorité des cas, la solution saine est de reporter ce qui est nécessaire en plugin ou dans un thème, pour éviter de garder un core non standard.
Quand un core a été modifié, je traite la vérification comme un outil de décision. Soit vous ramenez le core au standard et vous re-déployez le changement via un composant contrôlé, soit vous documentez précisément les modifications et vous assumez le risque. Sur un site compromis, l’assumer est rarement confortable.
Le contrôle échoue à cause de l’édition de fichiers ou d’un upgrade interrompu
Il arrive que des caches ou des mises à jour aient laissé des fichiers partiellement remplacés. Vous verrez alors des écarts sans malware direct, juste une installation incohérente.
Dans ce contexte, la restauration du core depuis l’archive officielle peut résoudre le problème sans qu’il faille tout “purger”. Mais je garde toujours une étape de vérification au-delà du core, parce qu’un site dont l’upgrade s’est mal passé a parfois aussi eu un coup de pression sur l’accès.
Multisite et environnements complexes
Sur multisite, on peut avoir des comportements différents selon les fichiers chargés, les networks settings, et la façon dont WordPress gère certains composants. La vérification du core reste utile, mais l’analyse des résultats doit tenir compte de la structure du réseau et des configurations spécifiques.
Si vous avez accès au réseau admin, vérifiez aussi les thèmes et plugins activés au niveau du réseau. Un compromis sur une seule extension réseau peut suffire à produire des symptômes sur tout le site.
Stratégie pratique après découverte d’un core altéré
Une fois que vous savez que le noyau n’est pas conforme, il faut choisir une action proportionnée. Remplacer tout le core est souvent la stratégie la plus simple et la plus rapide, mais elle demande prudence et discipline.
Ce que je recommande, en pratique, est une séquence:
- Restaurer le core avec une source officielle pour éliminer le risque de code injecté dans wp-admin et wp-includes. Conserver un état “observatoire” avant restauration, via backup et journal de ce qui a été détecté. Relancer des tests fonctionnels ciblés: pages sensibles, formulaires, chargements qui provoquent la redirection ou l’injection. Ensuite, passer au nettoyage malware WordPress des zones qui ne sont pas couvertes par le core: plugins, thèmes, uploads, planificateur (cron) et utilisateurs. Enfin, durcir: permissions, mises à jour, suppression des comptes inutiles, rotation des mots de passe compromis, validation des règles d’accès.
Le point important: si vous remplacez le core mais que vous ne corrigez pas la cause d’accès, vous verrez probablement une réinfection. C’est fréquent quand la https://gardewp.fr/nettoyage-malware-wordpress/ faille vient d’un plugin vulnérable ou d’identifiants compromis.
Durcissement après vérification, pour éviter la “mauvaise répétition”
La vérification du core est utile, mais le gain durable vient du durcissement, autrement dit rendre plus difficile la modification furtive. Le core non conforme est souvent le symptôme d’un problème plus large: autorisations, exposition, pratiques de déploiement.
Sans partir dans un guide système exhaustif, je vise surtout le niveau de décision:
- Limiter les droits d’écriture aux dossiers nécessaires, surtout dans l’arborescence WordPress. Empêcher l’exécution de scripts dans les zones d’upload, selon votre serveur. Contrôler l’accès aux comptes admin et restreindre les sessions. Désactiver ou supprimer les thèmes et plugins inutiles, et vérifier ce qui a été ajouté récemment. Mettre en place une routine de mise à jour, mais pas une mise à jour “au hasard” après un incident. D’abord, on stabilise et on prouve.
C’est souvent là que l’intervention s’étire. On ne veut pas seulement “nettoyer”. On veut refaire un site qu’on peut administrer sereinement.
Et si votre objectif est la preuve, pas seulement la réparation ?
Dans certains contextes (responsabilité, audits, incident chez un client), on ne cherche pas uniquement à remettre en ligne. On veut pouvoir dire: “voici ce qui diffère, et voici ce qui a été restauré”.
Dans ce cas, la vérification d’intégrité devient un outil de documentation. Les logs de WP-CLI, les listes de fichiers modifiés, et une trace de la version de WordPress utilisée sont des éléments concrets. Pour la comparaison manuelle, conservez les sorties de hashes (ou au moins une capture structurée) et les références d’archives employées.
Le plus important: ne faites pas de manipulation “en temps réel” sans garder une trace. Si vous remplacez directement sans enregistrer quoi que ce soit, vous perdez la capacité d’expliquer l’incident, et vous courez plus de risques de recommencer au lieu d’en finir.
Choisir la bonne méthode selon votre contexte
Si vous avez accès shell et WP-CLI, démarrez par la vérification des checksums, puis restaurez le core si nécessaire. Si vous n’avez pas WP-CLI, la comparaison avec archive officielle reste la méthode la plus fiable, même si elle demande plus de temps.
Dans les environnements contraints, la restauration du core comme test peut être un bon compromis, à condition d’enchaîner par un nettoyage plus large. Le core propre sans contrôle des plugins, des thèmes, des uploads et de la base, c’est un dossier incomplet.
Si vous voulez une règle simple issue de l’expérience: dès que le core est altéré, vous traitez le site comme compromis, vous remettez le core au standard, puis vous repartez sur une enquête complète. C’est plus long que “désinstaller l’extension suspecte”, mais au moins vous évitez la réinfection en boucle.
Protéger le futur : intégrer la vérification dans vos routines
Après un incident, beaucoup d’équipes retombent dans leurs habitudes. Pour éviter ça, vous pouvez rendre la vérification d’intégrité “naturelle” dans votre maintenance.
Concrètement, vous pouvez viser une routine après chaque mise à jour majeure, ou à chaque fois qu’un changement inattendu est observé (nouvelle redirection, création d’un compte admin, modification d’options). Le coût est généralement inférieur à l’effort de réenquête quand vous ne savez plus pourquoi le site a changé.
Et surtout, la vérification du noyau donne une boussole. Elle vous dit où regarder en premier, au lieu de courir derrière des symptômes. C’est exactement ce qu’on veut quand on fait un nettoyage malware WordPress sérieux, pas juste un pansement.