Vérifier les checksums WordPress : fichiers core modifiés

Si vous soupçonnez un piratage, vérifier les checksums WordPress est un bon premier contrôle, mais il ne doit retarder ni le confinement ni la préservation des preuves. Une seule commande indique si les fichiers de votre core sont strictement identiques à la version officielle. Les fichiers couverts par la liste officielle de checksums doivent correspondre à votre version exacte et à votre langue. Les fichiers propres au site, comme wp-config.php, sont hors de cette comparaison. Tout écart est soit une modification locale que vous connaissez, soit quelque chose à examiner dès aujourd'hui.

Pourquoi les fichiers du core WordPress changent après un piratage

Les fichiers du core sont une bonne cachette, parce que personne ne les lit. Les propriétaires de site regardent les réglages de leur thème et de leurs extensions. Presque personne n'ouvre wp-includes/load.php ni ne compte les fichiers de wp-admin/includes. Un attaquant peut dissimuler du code dans un fichier du core chargé en permanence, ou ajouter un fichier au nom vraisemblable pour s'en servir plus tard. Un fichier ajouté ne s'exécute pas pour autant du simple fait qu'il se trouve dans un répertoire du core.

Les checksums transforment « ça a l'air normal » en comparaison vérifiable. WordPress.org publie un hachage MD5 pour chaque fichier du core de chaque version. Vous comparez vos fichiers à cette liste.

Gardez toutefois la cause en tête. Le rapport State of WordPress Security in 2026 de Patchstack, un éditeur de solutions de sécurité, ne recense que 6 vulnérabilités dans le core de WordPress en 2025, toutes de faible priorité. Ce chiffre ne dit pas comment un attaquant est entré sur votre site. Des fichiers du core modifiés peuvent résulter d'une intrusion par une extension, un thème ou des identifiants volés. Remplacer le core répare ces fichiers, mais il reste à identifier et à fermer la porte d'entrée.

Vérifier les checksums WordPress avec WP-CLI

Connectez-vous en SSH et lancez la commande depuis le répertoire racine de WordPress :

cd /var/www/example.com
wp core verify-checksums

Si vous êtes dans un autre répertoire, ajoutez --path=/var/www/example.com. Exécutez la commande avec l'utilisateur propriétaire des fichiers du site, pas en root. WP-CLI refuse de s'exécuter en root sans l'option --allow-root, et ce comportement par défaut est judicieux : en root, tout code malveillant chargé par WordPress s'exécuterait lui aussi en root.

Par défaut, WP-CLI lit la version dans wp-includes/version.php. Sur un site compromis, ce fichier peut lui aussi avoir été modifié. Si vous savez quelle version vous avez installée, imposez-la. Pour une installation non anglophone, précisez aussi la locale :

wp core verify-checksums --version=6.8.3 --locale=de_DE

Utilisez votre propre numéro de version (et fr_FR pour une installation française). Sur un site sain, vous obtenez une seule ligne :

Success: WordPress installation verifies against checksums.

Sur un site à problème, vous obtenez des avertissements de ce type :

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Interpréter les résultats : fichiers modifiés ou fichiers en trop

Les deux types d'avertissement n'ont pas la même signification et appellent des réactions différentes.

Prenez un fichier modifié au sérieux, sauf si vous savez qu'un correctif local légitime a été appliqué. Ces correctifs sont rares, et celui qui en a posé un aurait dû le documenter.

Un fichier en trop est moins tranché. Certaines mises à jour laissent derrière elles des fichiers d'anciennes versions : sa présence ne prouve donc pas la présence d'un malware. En revanche, un fichier PHP au nom aléatoire dans wp-includes reste suspect tant que vous ne l'avez pas lu. Il en va de même pour un fichier dont le nom ressemble seulement à celui d'un composant du core.

Les fichiers en trop peuvent être signalés par de simples avertissements, sans que la commande échoue : vous pouvez voir des lignes File should not exist suivies de Success. Lisez chaque avertissement plutôt que de vous fier à la dernière ligne.

Par défaut, la recherche de fichiers en trop porte sur wp-admin et wp-includes. Certaines versions de WP-CLI peuvent aussi contrôler la racine. Lancez wp help core verify-checksums pour savoir si votre version propose --include-root.

Pas de WP-CLI ? Utilisez l'API de checksums de WordPress.org

Certains hébergeurs proposent le SSH sans WP-CLI. Dans ce cas, interrogez directement l'API de checksums et laissez md5sum comparer les fichiers. Il vous faut curl et jq :

cd /var/www/example.com
VER=6.8.3        # votre version exacte de WordPress
LOC=en_US        # ou de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

Le filtre select écarte les thèmes et extensions fournis avec WordPress dans wp-content, que vous avez peut-être supprimés volontairement. Avec --quiet, md5sum n'affiche que les fichiers en échec.

Aucune sortie et un code de retour nul signifient que les fichiers de la liste filtrée concordent. Une erreur de téléchargement, d'analyse ou de vérification n'est pas un résultat propre. Le sous-shell utilise un répertoire temporaire privé et s'arrête dès qu'une étape échoue.

Cette méthode ne détecte pas les fichiers en trop. Pour les trouver, téléchargez la même version, par exemple https://wordpress.org/wordpress-6.8.3.zip. Pour une installation non anglophone, utilisez le site de la locale correspondante. Décompressez l'archive et comparez les dossiers :

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

Les lignes Only in /var/www/... désignent des fichiers installés en trop. Les lignes Only in wordpress/... désignent des fichiers manquants dans l'installation. Les lignes Files ... differ signalent des différences de contenu. Examinez aussi les répertoires inattendus.

Extensions et thèmes : là où les checksums s'arrêtent

WP-CLI sait aussi contrôler les extensions :

wp plugin verify-checksums --all

Cela ne fonctionne que pour les extensions hébergées sur WordPress.org, car elles seules disposent de checksums publiés. Une extension sans jeu de checksums correspondant sur WordPress.org ne peut pas être vérifiée de cette façon.

Si une copie piratée (« nulled ») ou altérée conserve le slug et la version d'une extension de WordPress.org, la commande peut quand même la comparer et signalera les fichiers modifiés. WP-CLI n'a pas de commande intégrée équivalente pour les thèmes.

Pour ces extensions et pour les thèmes, récupérez la version exacte installée auprès de sa source officielle ou d'une archive de build de confiance. Pour du code sur mesure, partez d'une version livrée dont vous êtes sûr, jamais d'une copie prélevée sur le site suspect. Comparez ensuite avec la copie installée :

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Cherchez aussi les dossiers d'extension que vous ne parvenez à rattacher à rien de ce que vous avez installé. Un dossier inconnu dans wp-content/plugins est un signal d'alarme. Une extension « nulled » pose problème en soi, quel que soit le résultat du diff. Le guide sur les vulnérabilités des extensions explique comment remplacer les extensions piratées et abandonnées.

Réinstaller le core de WordPress en toute sécurité

Commencez par sauvegarder les preuves et faire une sauvegarde complète. Remplacez ensuite le core par une copie propre de la même version :

wp core download --force --skip-content --version=6.8.3

Ajoutez --locale=de_DE ou votre langue si nécessaire. La commande écrase les fichiers du core. Elle ne touche pas à wp-config.php, puisque le paquet ne contient aucun fichier de ce nom. --skip-content laisse wp-content intact.

La commande ne supprime pas les fichiers en trop. Un fichier comme wp-includes/class-wp-cache-handler.php reste en place, car le téléchargement n'écrit que des fichiers officiels. Copiez et examinez d'abord chaque fichier en trop. Supprimez ensuite ceux qui sont malveillants ou dont vous avez confirmé qu'ils sont inutiles. Relancez wp core verify-checksums et vérifiez qu'il ne reste aucun avertissement inexpliqué.

Ce qu'un résultat propre ne vous dit pas

Un résultat vert ne couvre que le core de WordPress. Il ne dit rien sur :

• wp-content : thèmes, extensions premium et sur mesure, mu-plugins et uploads
• wp-config.php et .htaccess, qui ne figurent pas dans la liste de checksums
• La base de données : options injectées, spam dans les articles, comptes administrateur illégitimes, événements cron planifiés
• Les fichiers extérieurs à WordPress, comme d'autres fichiers PHP du compte d'hébergement ou la configuration du serveur

Les attaquants savent quels fichiers sont contrôlés. C'est l'une des raisons pour lesquelles wp-content/uploads est un emplacement de prédilection pour les web shells. Parcourez les signes d'un site piraté pour les autres contrôles. Pour les uploads, appuyez-vous sur le guide sur les web shells.

Surveiller l'intégrité des fichiers dans la durée

Un contrôle ponctuel aide pendant un incident. Un contrôle planifié peut réduire le temps pendant lequel une modification passe inaperçue, mais des changements peuvent toucher les visiteurs avant la prochaine exécution. Un petit script lancé par cron suffit :

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Installez-le dans la crontab du propriétaire du site, pas dans celle de root. Le script déclenche une alerte sur un code de retour non nul et sur tout avertissement, y compris les fichiers en trop signalés. Définissez un PATH connu ou utilisez des chemins complets, car cron dispose d'un environnement restreint. Vérifiez qu'une alerte arrive réellement ; remplacez mail par votre système d'alerte opérationnel si nécessaire.

Pour wp-content, conservez votre propre référence après chaque mise à jour dont vous êtes sûr :

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Stockez cette référence en dehors de la racine web, idéalement hors du serveur. Pour détecter des changements, lancez sha256sum -c --quiet avec cette référence depuis la racine du site. Vous repérerez ainsi les fichiers modifiés et supprimés, mais pas les nouveaux. Pour ceux-ci, comparez une nouvelle liste obtenue avec find à celle de la référence. Créez une nouvelle référence après chaque mise à jour légitime, faute de quoi le contrôle suivant signalera vos propres changements.

Des contrôles réguliers contribuent aussi à la conformité. L'article 32, paragraphe 1, point d) du RGPD exige une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité de vos mesures de sécurité. Un contrôle d'intégrité planifié, dont les résultats sont conservés, constitue une preuve concrète de cette procédure. Pour une vue d'ensemble, voir l'article 32 du RGPD appliqué à WordPress.

Si vous préférez ne pas maintenir de scripts, l'extension Security Audit & Compliance de secaudit.eu tient à jour une référence d'intégrité des fichiers et signale les fichiers modifiés ainsi que le contenu obfusqué. Elle exécute aussi la vérification des checksums du core. Elle détecte et signale ; le nettoyage reste à votre charge ou à celle de votre agence.

FAQ

verify-checksums fonctionne-t-il en multisite et avec une installation non anglophone ?

Oui. Un réseau multisite partage un seul jeu de fichiers du core : une exécution couvre donc tout le réseau. Pour une installation non anglophone, indiquez la bonne valeur de --locale, car les paquets localisés peuvent différer de en_US.

Un avertissement « File should not exist » signale-t-il toujours un malware ?

Non. Des fichiers laissés par d'anciennes versions de WordPress le déclenchent aussi. Gardez une copie et examinez le fichier. Supprimez-le s'il est malveillant ou si vous avez confirmé qu'il est inutile. Du code PHP inexpliqué dans un dossier du core mérite toujours un examen sérieux.

À quelle fréquence faut-il lancer la vérification ?

Un passage quotidien par cron est raisonnable pour la plupart des sites d'entreprise. Lancez-la aussi après un incident, après chaque mise à jour du core et chaque fois qu'une nouvelle personne obtient un accès au serveur.

Un pirate peut-il falsifier le résultat de la vérification ?

Les checksums eux-mêmes proviennent de WordPress.org en HTTPS. Un attaquant qui contrôle votre serveur pourrait en revanche altérer les outils locaux, comme le fichier WP-CLI ou les binaires système. En cas de doute, copiez les fichiers du site sur une machine saine et comparez-les là-bas à un téléchargement neuf de la même version.