En bref : pour vérifier les fichiers du noyau d'un CMS, comparez les fichiers installés avec un original sain de la même version : pour WordPress via les sommes de contrôle officielles, pour les autres systèmes via un téléchargement frais ou une reconstitution à partir de composer.lock. Chaque écart est une vérification à mener. La comparaison trouve aussi du code malveillant inconnu, mais ne couvre que les fichiers pour lesquels il existe un original.
Pourquoi la comparaison trouve plus que n'importe quelle signature
Les scanners de logiciels malveillants recherchent des motifs connus. Ce qu'ils ne connaissent pas, ils le manquent. Une comparaison avec l'original fonctionne à l'inverse : elle ne demande pas si un fichier a l'air suspect, mais s'il correspond exactement à ce que l'éditeur a livré. Chaque écart ressort, qu'il suive ou non un motif connu.
Après PHP2Shell, c'est particulièrement précieux. Pour les failles CVE-2026-109618 et CVE-2026-109619, il n'existe pas d'indicateurs de compromission publiés et confirmés. Les scanners ne peuvent donc pas rechercher de façon ciblée des traces de PHP2Shell. Une comparaison avec l'original trouve en revanche toute modification du noyau, quelle que soit la façon dont elle est survenue. L'article Scanners de logiciels malveillants pour sites web : ce qu'ils trouvent et ce qu'ils manquent explique pourquoi les scanners seuls ne suffisent pas.
Le principe : même version, source saine
Une comparaison ne vaut que par sa référence. Trois conditions doivent être remplies :
- Exactement la même version : une comparaison avec une version plus récente montre des centaines de différences inoffensives. Déterminez la version installée à partir de l'application ou de
composer.lock. - Source officielle : l'original provient de l'éditeur, du répertoire officiel de paquets ou de votre propre système de gestion de versions. Pas d'une ancienne sauvegarde du serveur concerné.
- Comparaison sur une copie : travaillez sur une copie sécurisée du répertoire web afin que les horodatages et les traces soient conservés.
| Système | Référence | Outil |
|---|---|---|
| Noyau WordPress et plugins du répertoire | sommes de contrôle de WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Projets Composer (par ex. Shopware 6, Laravel, Symfony, Drupal, TYPO3 en mode Composer) | reconstitution à partir de composer.lock |
composer install dans un répertoire vide, puis diff |
| CMS avec paquet à télécharger | paquet de la même version chez l'éditeur | diff -rq |
| Projets personnels avec Git | dernier commit connu | git status, git diff |
| Paquets système du serveur | base de données de paquets de la distribution | dpkg --verify, rpm -Va |
WordPress : plus que verify-checksums
La manière de vérifier le noyau et les plugins avec WP-CLI est décrite dans le guide Trouver les portes dérobées dans WordPress. Un complément vaut la peine : selon la documentation de WP-CLI, l'option --include-root vérifie tous les fichiers et dossiers du répertoire principal et signale les éléments qui n'appartiennent pas à WordPress. C'est là que les attaquants déposent volontiers des fichiers dont les noms rappellent des fichiers du noyau.
# Noyau comparé aux sommes de contrôle officielles, y compris les fichiers étrangers du répertoire principal
wp core verify-checksums --include-root
Les plugins et thèmes commerciaux ne sont pas couverts par cette voie. Pour eux, téléchargez chez l'éditeur le paquet d'origine de la même version et comparez avec diff.
Vérifier les fichiers du noyau d'un CMS dans les projets Composer
De nombreuses applications PHP modernes sont constituées en majeure partie de paquets installés par Composer, le gestionnaire de paquets pour PHP. Son fonctionnement est expliqué sur la page Composer : le gestionnaire de paquets pour PHP. Le fichier composer.lock consigne exactement quelles versions sont installées. Selon la documentation de Composer, composer install utilise ces versions exactes. L'état de livraison peut ainsi être reconstitué :
# Sur un système sain, pas sur le serveur concerné
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Lister les différences dans le dossier vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Les options --no-scripts et --no-plugins empêchent l'exécution de scripts issus des paquets lors de la reconstitution. Si la production a été installée avec --no-dev, utilisez aussi cette option lors de la reconstitution, sinon les paquets de développement apparaissent comme une différence. Soyez attentif à deux types de résultats : les fichiers qui diffèrent et les fichiers qui n'existent que sur le serveur. Le second groupe est souvent le plus intéressant. Le guide Vérifier les failles des dépendances Composer décrit comment vérifier en plus les paquets installés par rapport aux failles connues.
Comparer aussi le système d'exploitation
Si un attaquant a eu les droits root, il peut aussi avoir remplacé des programmes système. Les gestionnaires de paquets intègrent leur propre comparaison :
# Debian, Ubuntu : fichiers dont le contenu diffère du paquet
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky : vérifier tous les paquets
sudo rpm -Va
Un 5 en troisième position de la sortie signifie que le contenu d'un fichier a changé. Selon le manuel de dpkg, la comparaison du contenu y est actuellement la seule vérification efficace. Les fichiers de configuration modifiés sont normaux et marqués par c. Un programme modifié dans /usr/bin, en revanche, est un sérieux signal d'alarme. Attention : un attaquant disposant des droits root peut aussi manipuler la base de données des paquets. En cas de soupçon d'accès root, une reconstruction est plus fiable que n'importe quelle comparaison.
Un système de gestion de versions pour le code de l'application rend les comparaisons futures l'affaire de quelques secondes. git status montre alors chaque écart par rapport à l'état validé.
Évaluer les écarts et connaître les limites
Tout écart n'est pas une attaque. Certaines agences ont autrefois adapté directement les fichiers du noyau au lieu d'utiliser des extensions. Les paquets de langue, les fins de ligne après un transfert par FTP ou des correctifs appliqués après coup produisent également des différences. L'essentiel est de savoir si quelqu'un peut expliquer la modification.
Passez chaque écart en revue individuellement et notez le résultat : connu et documenté, explicable et sans danger, ou flou. Les fichiers flous, ouvrez-les uniquement comme texte sur une copie et remplacez-les à partir de la source saine. Pour les fichiers qui n'existent que sur le serveur, la question est plus simple : si personne ne les connaît, il faut les sauvegarder et les faire supprimer après avoir vérifié leur contenu.
Les uploads, les fichiers de configuration comme wp-config.php ou .env, les adaptations personnelles et les caches n'ont pas d'original. Ils doivent être examinés de façon ciblée, de même que la base de données, les tâches cron, les comptes utilisateurs et les clés SSH. Une comparaison propre est donc un élément important, mais pas un acquittement pour le serveur entier.
Comment PHP SOS aide-t-il concrètement ?
- Nous déterminons les versions installées et construisons une référence saine à partir de sources officielles.
- Nous comparons le noyau, les extensions, les paquets Composer et les programmes système et évaluons chaque écart.
- Nous examinons de façon ciblée les zones sans original et remplaçons les fichiers modifiés à partir d'une source saine dans le cadre de la suppression de logiciels malveillants.
- Sur demande, nous mettons en place un état de version par rapport auquel les vérifications futures s'exécuteront.
Questions fréquentes
Comment vérifier si les fichiers du noyau de WordPress ont été modifiés ?
Avec WP-CLI et la commande wp core verify-checksums. Elle compare les fichiers aux sommes de contrôle que WordPress.org publie pour la version installée. Avec l'option --include-root, WP-CLI signale en plus les fichiers du répertoire principal qui n'appartiennent pas à WordPress.
Que faire avec un CMS sans fonction de vérification intégrée ?
Vous téléchargez exactement la même version depuis la source officielle de l'éditeur et comparez les deux répertoires avec diff. Pour les projets Composer, reconstituez l'état à partir de composer.lock dans un répertoire vide et comparez le dossier vendor.
La comparaison trouve-t-elle aussi le code malveillant dans les plugins et les thèmes ?
Seulement s'il existe un original sain pour eux, par exemple dans le répertoire officiel ou chez l'éditeur. Les adaptations personnelles, les uploads et les fichiers de configuration n'ont pas d'original et doivent être examinés séparément.
La comparaison remplace-t-elle un scanner de logiciels malveillants ?
Elle le complète. La comparaison trouve toute modification de fichiers connus, y compris du code malveillant inconnu. Mais elle ne dit rien des fichiers sans original, de la base de données, des tâches cron ou des accès.