En bref : si php -v affiche la même version après la mise à jour, c'est le plus souvent dû à un rétroportage : la distribution ne reprend que la correction de sécurité dans sa version PHP existante, le numéro reste le même. Ubuntu 24.04 affiche ainsi toujours 8.3.6, bien que le paquet soit corrigé contre PHP2Shell. Tranchez la question via le niveau du paquet et le changelog, et vérifiez en plus que le site tourne réellement avec le nouveau code.
Un moment typique après PHP2Shell
L'admin a installé la mise à jour, sans erreur. Pour contrôler, il tape php -v et voit la même version qu'avant. La mise à jour n'a-t-elle pas fonctionné ? Le serveur est-il toujours ouvert ? Cette question figure parmi les plus fréquentes depuis le 21 octobre 2026.
La bonne nouvelle : dans la plupart des cas, tout est en ordre. La mauvaise : il existe aussi des cas où le même numéro indique réellement un problème. Cet article aide à distinguer les deux.
Pourquoi les distributions ne changent pas le numéro
Les distributions d'entreprise et LTS promettent la stabilité. Au sein d'une version, le comportement et les interfaces ne doivent si possible pas changer. Un saut de PHP 8.3.6 à 8.3.36 apporterait toutefois de nombreuses corrections d'erreurs et de petits changements de comportement qui pourraient perturber des applications.
C'est pourquoi de nombreux mainteneurs de paquets ne reprennent que la correction de sécurité précise dans leur version existante. Ce procédé s'appelle rétroportage (backport). La version amont, que PHP indique lui-même via php -v, reste la même. Ce qui change, c'est le niveau du paquet, attribué par la distribution.
Sur l'exemple d'Ubuntu 24.04 : PHP indique 8.3.6. Le niveau de paquet corrigé est toutefois, selon USN-8948-1, 8.3.6-0ubuntu0.24.04.13. La partie arrière compte. Debian a décidé autrement pour PHP2Shell et livré pour bookworm et trixie les nouvelles versions amont 8.2.35 et 8.4.27. Le récapitulatif par version figure dans l'article Debian et Ubuntu : mon paquet PHP est-il corrigé ?.
Il vaut la peine de décomposer une fois une telle version de paquet. Sur l'exemple 8.3.6-0ubuntu0.24.04.13 : la partie avant le tiret est la version amont, donc ce que PHP indique lui-même. Derrière suit la révision de la distribution. ubuntu0.24.04 renvoie à la version, le dernier nombre compte les révisions. Chaque correction de sécurité augmente ce nombre. Avec Ubuntu Pro apparaît en plus un suffixe comme +esm5, avec les mises à jour de sécurité Debian un suffixe comme ~deb12u1. Qui sait lire ces parties reconnaît d'un coup d'œil si un paquet a été modifié après un avis de sécurité.
Où l'ancien numéro apparaît partout
Le numéro inchangé n'apparaît pas seulement dans php -v. Il figure aussi à des endroits visibles de l'extérieur ou exploités par des outils :
| Lieu | Ce qui y figure | Conséquence |
|---|---|---|
php -v et php -i |
version amont, date de build | les admins doutent de la mise à jour |
| page phpinfo | version amont | même effet dans le navigateur |
en-tête X-Powered-By |
version amont, si expose_php est activé |
les scanners externes signalent une faille |
| panneaux d'hébergement comme Plesk | version amont | affichage par exemple de 8.2.34 malgré le correctif |
| scanners de vulnérabilités | comparaison par numéro | fausse alerte avec les rétroportages |
Les scanners externes sont un cas à part. Qui les utilise reçoit après PHP2Shell peut-être des détections pour des serveurs corrigés depuis longtemps. N'ignorez pas ces détections en bloc, mais justifiez pour chaque serveur le niveau du paquet et consignez la détection comme vérifiée. Une autre raison de masquer les indications de version vers l'extérieur figure dans l'article expose_php et en-têtes du serveur.
Quand le même numéro est un signal d'alerte
Il y a trois situations où le numéro inchangé indique réellement un problème :
- La source de paquets livre la version amont. Si PHP vient d'une source qui livre normalement la version amont actuelle, par exemple Debian pour PHP2Shell ou des sources tierces comme Remi et sury.org, 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 devrait apparaître après la mise à jour. Si l'ancien numéro figure toujours, le paquet n'a pas été mis à jour.
- Vous vérifiez la mauvaise installation.
php -vmontre la ligne de commande. Si le site tourne via une autre version, par exemple issue d'un panneau d'hébergement ou d'une Software Collection, la sortie ne dit rien sur le site. - Le niveau du paquet n'a pas changé. Si le niveau du paquet est aussi le même qu'avant la mise à jour, la mise à jour n'est pas arrivée pour ce paquet, par exemple parce qu'il a été retenu ou que la source manque.
Pour les non-techniciens, cela se résume ainsi : le numéro de version décrit le modèle, le niveau du paquet l'état de maintenance. Deux serveurs avec la même version de PHP peuvent différer nettement en matière de sécurité. Ne demandez donc pas la version à votre informatique ou prestataire, mais la preuve du correctif.
Comment trancher en cinq minutes
Les commandes suivantes sont en lecture seule. Les exemples supposent Ubuntu ou Debian et PHP 8.3 ; sur les systèmes RHEL, utilisez rpm -q plutôt que dpkg-query.
# 1. Que signale PHP lui-même, date de build comprise ?
php -v
# 2. Quel niveau de paquet est installé, de quelle source ?
apt policy php8.3-fpm
# 3. Le changelog contient-il les numéros CVE ?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Depuis quand les processus PHP du site tournent-ils ?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
La date de build dans la sortie de php -v est un indice, mais pas une preuve. La preuve fiable est fournie par l'entrée du changelog. La manière de la trouver et de la consigner lorsqu'elle est formulée autrement ou manque est décrite dans l'article Prouver les numéros CVE dans le changelog du paquet.
Après chaque vérification, notez les deux numéros : la version amont de php -v et le niveau du paquet. Qui demande plus tard pourquoi le serveur est « encore en 8.3.6 » obtient ainsi une réponse claire.
La vérification générale via version, paquet et processus est résumée sur la page Bien vérifier la version de PHP et le niveau de correctif.
Comment PHP SOS aide-t-il concrètement ?
- Nous clarifions pour chaque serveur si un numéro de version inchangé est un rétroportage ou une mise à jour manquante.
- Nous évaluons les détections des scanners de vulnérabilités et justifions les fausses alertes par le niveau du paquet et le changelog.
- Nous vérifions quelle installation PHP le site utilise réellement et si ses processus ont été redémarrés.
- Dans le service de correctifs PHP, nous documentons côte à côte la version amont et le niveau du paquet.
Questions fréquentes
Mon serveur est-il non corrigé si php -v affiche l'ancien numéro ?
Pas nécessairement. De nombreuses distributions reprennent les corrections sous forme de rétroportage dans la version existante. Ubuntu 24.04 affiche par exemple toujours 8.3.6, bien que le paquet soit corrigé selon USN-8948-1. Ce qui compte, ce sont le niveau du paquet et le changelog.
Pourquoi mon scanner de sécurité signale-t-il une faille malgré la mise à jour ?
De nombreux scanners ne lisent que le numéro de version, par exemple dans l'en-tête X-Powered-By. Avec les rétroportages, cela conduit à de fausses alertes. Vérifiez le niveau du paquet et documentez le résultat plutôt que d'ignorer simplement la détection.
Est-il possible que php -v affiche un nouveau numéro, mais pas le site ?
Oui. php -v montre la ligne de commande. Le site peut tourner via une autre installation ou via des processus démarrés avant la mise à jour. Vérifiez donc aussi le service FPM ou Apache et leur heure de démarrage.
La date de build dans la sortie de php -v aide-t-elle ?
C'est un indice, mais pas une preuve. Une date de build postérieure au 21 octobre 2026 correspond à un paquet corrigé, mais ne prouve pas que la correction est incluse. L'entrée du changelog est la meilleure preuve.