Le principe : une empreinte par fichier
Pour chaque version de WordPress, le projet publie une empreinte cryptographique (un checksum MD5) de chaque fichier du core. Cette empreinte change dès qu'un seul octet du fichier est modifié. Comparer le fichier présent sur votre serveur à la valeur officielle revient donc à poser une question binaire : ce wp-login.php est-il exactement celui livré par WordPress.org, ou quelqu'un l'a-t-il touché ?
La force de la méthode est là : contrairement à la recherche de signatures, elle ne peut pas produire de « peut-être ». Une ligne ajoutée en fin de fichier, un caractère changé — l'empreinte ne correspond plus, et c'est détecté avec certitude.
Pourquoi c'est efficace contre les infections du core
Une technique de persistance classique consiste à greffer quelques lignes dans un fichier légitime très fréquenté — wp-load.php, index.php, wp-config.php. Le fichier continue de fonctionner, l'ajout passe inaperçu à l'œil nu au milieu de centaines de lignes légitimes. La recherche de signatures peut le manquer si le code ajouté est anodin en apparence. La vérification d'intégrité, elle, le voit toujours : le fichier n'est plus l'original, un point c'est tout.
La limite qu'il faut connaître : core uniquement
WordPress.org ne publie les checksums que du core — les fichiers de WordPress lui-même. Il n'existe pas d'équivalent officiel, exhaustif et centralisé pour les milliers de thèmes et d'extensions du répertoire, et encore moins pour ceux distribués hors répertoire.
Concrètement, cette méthode couvre parfaitement wp-admin/ et wp-includes/, mais pas wp-content/ — là où résident vos thèmes, vos extensions et vos téléversements. Or c'est justement dans wp-content/uploads/ qu'un attaquant dépose le plus souvent son webshell. La vérification d'intégrité ne le verra pas : ce fichier n'a pas d'original auquel le comparer.
C'est pour cette raison qu'aucun outil sérieux ne s'appuie sur les checksums seuls. Ils forment une brique — la plus fiable pour le core — qui doit être complétée par une analyse de signatures sur tout le reste.
Le cas du faux positif attendu
Tous les écarts de checksum ne sont pas des infections. Le cas le plus fréquent est wp-config-sample.php : ce fichier est souvent personnalisé par l'hébergeur, et de toute façon jamais chargé par WordPress. Son empreinte diffère de l'original, mais le risque est négligeable.
C'est exactement le genre de cas que nous classons informatif plutôt qu'« infecté » : un écart réel, signalé par transparence, mais qui ne fait pas monter le score et n'appelle aucune action. Un outil qui compterait chaque divergence de checksum comme une menace afficherait un score alarmant sur des sites parfaitement sains.
Voir la vérification d'intégrité en action
Notre rapport d'exemple montre justement un écart de checksum réel sur wp-config-sample.php, classé « informatif » et non compté comme menace — sur un site dont le score reste à 0/100. Consultable sans créer de compte.
Les checksums couvrent le core ; pour le reste, voir comment nous détectons les webshells et backdoors.