En bref : pour vérifier une CVE dans le changelog, cherchez CVE-2026-109618 et CVE-2026-109619 dans le journal des modifications du paquet PHP installé : sous Debian et Ubuntu dans /usr/share/doc/<paket>/changelog.Debian.gz, sur les systèmes RPM avec rpm -q --changelog. Une occurrence, associée à l'état du paquet, à la comparaison avec l'avis de sécurité officiel et à l'heure du redémarrage, constitue une preuve solide. L'absence d'occurrence n'est pas encore la preuve d'une faille ouverte.
Pourquoi une preuve est plus que « nous avons appliqué le correctif »
Après PHP2Shell, beaucoup veulent savoir si leurs serveurs sont sûrs : la direction, le délégué à la protection des données, les clients liés par un contrat de sous-traitance, parfois l'assureur cyber. « Nous avons appliqué le correctif » ne suffit pas pour cela. Il faut un justificatif qu'un tiers peut vérifier.
Le numéro de version ne s'y prête souvent pas, car les distributions intègrent les correctifs sous forme de rétroportage et le numéro reste le même. Le changelog du paquet est une meilleure base. Il est rédigé par le mainteneur du paquet et, pour les mises à jour de sécurité, énumère en règle générale les numéros CVE corrigés.
Où se trouvent les changelogs
Chaque format de paquet a son propre emplacement. Le tableau suivant aide à trouver rapidement le bon endroit.
| Système | Emplacement du changelog | Commande de recherche |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (en ligne) | Archive de paquets de la distribution | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | Base de données des paquets RPM | rpm -q --changelog <paket> |
| Images de conteneurs | dans l'image, comme pour le système de base | exécuter la commande dans le conteneur |
Sous Debian et Ubuntu, le répertoire de documentation de certains paquets binaires renvoie par un lien symbolique vers un paquet commun, par exemple php8.3-common. Si zgrep ne trouve pas le fichier, regardez le répertoire avec ls -l /usr/share/doc/ | grep php.
Vérifier une CVE dans le changelog : la marche à suivre
Les commandes suivantes sont en lecture seule. Adaptez les noms de paquets à votre installation.
# Debian/Ubuntu : en local, sans réseau
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu : ligne d'en-tête de la dernière entrée avec l'état du paquet et la date
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Famille RHEL : entrée avec la date et l'état du paquet
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
Sous Debian et Ubuntu, l'état du paquet figure dans la ligne d'en-tête de chaque entrée, la date dans la ligne de fin. Avec RPM, les deux figurent dans la ligne au-dessus des entrées. Vous voyez ainsi non seulement si la CVE est mentionnée, mais aussi avec quel état du paquet. Comparez cet état avec celui qui est installé, par exemple avec dpkg-query -W ou rpm -q. S'ils concordent, le correctif est inclus dans le paquet en service.
Paquets de panneau et conteneurs
Les panneaux d'hébergement apportent leurs propres paquets PHP, par exemple Plesk ou cPanel. Ce sont aussi des paquets DEB ou RPM ordinaires, et leur changelog se lit avec les mêmes outils. Les fournisseurs y citent ou non les numéros CVE, ou seulement la nouvelle version de PHP, selon les cas. Si le paquet indique la version amont 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, cela suffit comme justificatif ; pour les rétroportages conservant l'ancien numéro, il vous faut la réponse du fournisseur.
Pour les conteneurs, la preuve appartient à l'image, pas à l'hôte. Vérifiez les paquets dans l'image à partir de laquelle le conteneur en cours d'exécution a été lancé, et notez en plus le digest de l'image. Ainsi, on pourra retrouver plus tard quel état tournait réellement, même si l'image a entre-temps été reconstruite sous le même tag.
Quand la CVE manque dans le changelog
Une entrée manquante peut avoir plusieurs causes. Passez-les en revue dans cet ordre :
- Mauvais paquet examiné : avec plusieurs branches ou sources PHP sur un serveur, la réponse se trouve souvent dans le changelog d'un autre paquet.
- Version amont au lieu de la CVE : si la source livre la nouvelle version amont, par exemple 8.4.27, le changelog peut ne contenir que « New upstream version ». Le numéro de version est alors lui-même la preuve, puisque php.net désigne les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 comme corrigées.
- Autre formulation : certains mainteneurs citent des numéros de bogue ou des identifiants d'avis comme GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp au lieu de la CVE.
- Comparaison avec l'avis de sécurité : si l'avis officiel de votre distribution, par exemple un USN ou le Debian Security Tracker, indique un état de paquet corrigé et que celui-ci ou un état plus récent est installé, c'est également une preuve. Pour Debian et Ubuntu, vous trouverez les états dans l'article Mon paquet PHP est-il corrigé ?, pour la famille RHEL sous RHEL, AlmaLinux et Rocky Linux.
- Interroger le fournisseur : pour les paquets de panneau, les builds d'hébergeur ou les sources tierces, seule une réponse écrite aide. Le guide Demander à l'hébergeur l'état des correctifs en propose un modèle.
Si aucune preuve ne ressort après ces étapes, traitez le serveur comme non corrigé et appliquez des mesures transitoires jusqu'à ce que la question soit réglée.
De l'occurrence à la preuve
Une occurrence dans le changelog prouve que le paquet contient le correctif. Elle ne prouve pas que les processus en cours l'utilisent. Une preuve complète comprend donc cinq informations par serveur et par installation PHP :
- serveur, branche PHP et mode d'exécution, par exemple PHP-FPM ou mod_php
- état du paquet installé et source du paquet
- référence dans le changelog ou renvoi à l'avis de sécurité officiel
- date de la mise à jour et heure de démarrage des processus PHP en cours
- nom de la personne ayant effectué la vérification et date de la vérification
Enregistrez les sorties brutes des commandes dans un fichier texte à côté de la preuve. Elles sont plus faciles à vérifier plus tard qu'un résumé fait de mémoire.
Une preuve ne répond qu'à la question de savoir si la faille était fermée à partir d'une certaine date. Pour la période antérieure, il vous faut les journaux à partir du 20 octobre 2026 et, le cas échéant, une recherche de traces. La marche générale de la vérification de version est décrite sur la page Vérifier correctement la version de PHP et l'état des correctifs.
Comment PHP SOS aide-t-il concrètement ?
- Nous parcourons les changelogs de tous les paquets PHP de vos serveurs et les comparons avec les avis de sécurité officiels.
- Lorsque les changelogs restent muets, nous clarifions l'état avec la distribution, l'éditeur du panneau ou l'hébergeur.
- Nous vérifions que les processus en cours ont été redémarrés après la mise à jour.
- Avec le service de correctifs PHP, vous recevez la preuve pour chaque serveur sous une forme que vous pouvez transmettre à des tiers.
Questions fréquentes
Pourquoi la version de PHP ne suffit-elle pas comme preuve ?
De nombreuses distributions reprennent les correctifs de sécurité sous forme de rétroportage, sans changer la version de PHP. Le numéro de version ne dit alors rien du correctif. Le changelog du paquet installé, lui, indique les numéros CVE corrigés.
Que signifie l'absence de la CVE dans le changelog ?
Cela peut signifier que le correctif manque. Mais il se peut aussi que le mainteneur du paquet ait formulé autrement, par exemple avec un numéro de bogue ou la version amont. Dans ce cas, comparez l'état du paquet avec l'avis de sécurité officiel ou interrogez le fournisseur.
Combien de temps dois-je conserver la preuve ?
Aussi longtemps qu'elle peut être pertinente pour des contrôles internes, des assureurs ou d'éventuelles questions de protection des données. Archivez-la avec les journaux à partir du 20 octobre 2026. Pour les délais précis, rapprochez-vous du délégué à la protection des données ou d'un conseil juridique.
Puis-je vérifier le changelog sans accès à Internet ?
Oui. Debian et Ubuntu stockent localement le changelog de chaque paquet sous /usr/share/doc, les systèmes RPM le conservent dans la base de données des paquets. Les deux se lisent sans réseau.