php2shell (CVE-2026-109618 / 109619) ne se vérifie pas avec php -v : où les numéros de version divergent entre FPM, Docker et distributions

Si le PHP qui traite les requêtes web (PHP-FPM, mod_php d'Apache, php-cgi, FrankenPHP, LiteSpeed) est antérieur à 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, il est touché par CVE-2026-109618 et CVE-2026-109619, connues sous le nom de php2shell. Le correctif consiste à passer à l'une de ces versions (ou, pour les paquets de distribution, au paquet corrigé) puis à redémarrer les processus. Ce qu'il faut vérifier, ce n'est pas le php -v de votre poste, mais « le PHP qui sert réellement le web » et « la version du paquet installé ».

Cet article se concentre sur quatre endroits où se fier au seul numéro de version mène à une mauvaise conclusion. Tous les chiffres et états sont au 2026-10-22 ; les sources de chaque point sont listées à la fin.

Ce que l'on sait au 2026-10-22

L'avis de PHP indique que « le seul correctif complet est la mise à jour ». Les mesures d'atténuation pour la période précédant la mise à jour sont présentées plus loin dans cet article.

Piège 1 : php -v et le PHP exposé au web peuvent être différents

Un php -v saisi en SSH indique la version du PHP CLI. Les requêtes web sont traitées par des processus PHP-FPM ou par mod_php chargé dans Apache, qui sont des binaires distincts issus de paquets distincts. Si vous n'avez installé un PHP plus récent que pour la CLI, si vous faites cohabiter plusieurs versions, ou si un pool FPM pointe vers une autre version, le côté web peut rester ancien même quand php -v affiche une version corrigée.

Plusieurs méthodes permettent de voir la version réelle côté web.

# FPM sur Debian / Ubuntu (nommé par version)
php-fpm8.3 -v

# FPM sur les systèmes de la famille RHEL
php-fpm -v

# Vérifier si mod_php est chargé dans Apache
apachectl -M | grep -i php

La méthode la plus fiable consiste à faire indiquer sa version par le PHP qui s'exécute réellement via le web. Placez un fichier temporaire au nom difficile à deviner, et supprimez-le dès que vous avez vérifié.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Si PHP_SAPI vaut fpm-fcgi, PHP tourne sous FPM ; apache2handler signifie mod_php ; cgi-fcgi signifie CGI. Évitez de laisser phpinfo() exposé, car cela divulgue en soi des informations.

Le redémarrage est une autre étape facile à oublier. Même après le remplacement du paquet, les processus php-fpm ou Apache déjà lancés peuvent continuer à exécuter l'ancien code. Certaines configurations redémarrent automatiquement lors des mises à jour de paquets, d'autres non. Après la mise à jour, redémarrez FPM / Apache et vérifiez à nouveau la version côté web avec les méthodes ci-dessus.

Piège 2 : avec Docker, le nom du tag ne suffit pas pour conclure

L'image officielle php propose des « tags mobiles » comme 8.3 et 8.3-fpm, dont le contenu est remplacé, et des tags figés comme 8.3.30, qui fixent la version.

• Même après qu'un tag mobile a été basculé vers une version corrigée sur Docker Hub, votre copie locale reste l'ancienne image tant que vous ne refaites pas un pull. Les conteneurs en cours d'exécution continuent aussi d'utiliser l'ancienne image tant qu'ils ne sont pas recréés. Un Dockerfile avec FROM php:8.3-fpm sera encore construit sur l'ancienne base si celle-ci reste dans le cache de build.
• Un tag figé reste ancien indéfiniment tant que vous ne changez pas vous-même le numéro.

Vous pouvez vérifier si des tags de versions corrigées ont été publiés grâce à l'API de Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Voici les résultats de l'interrogation de quatre séries de versions le 2026-10-22 (heures en UTC).

Cette vérification a fait apparaître trois points où se fier aux numéros peut induire en erreur.

1. « Mis à jour récemment » ne veut pas dire « corrigé ». Le tag figé 8.3.35 a été reconstruit au cours du 2026-10-21, mais la PHP_VERSION à l'intérieur était toujours 8.3.35. Regardez la version à l'intérieur, pas la date de mise à jour.
2. Des digests différents peuvent correspondre au même contenu. 8.3 et 8.3.36 avaient des digests de tag différents (la valeur de l'index multi-architecture), mais l'image amd64 était identique et les deux avaient PHP_VERSION=8.3.36. De même, pour 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm et 8.2-fpm, la PHP_VERSION de l'image amd64 était une version corrigée.
3. Il n'existe pas d'images officielles corrigées pour 8.1 et antérieures. 8.1-fpm a été mise à jour pour la dernière fois le 2025-12-31.

Pour vérifier vos images locales et vos conteneurs en cours d'exécution :

# Version de PHP d'une image déjà récupérée localement
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Refaire un pull et recréer les conteneurs
docker compose pull
docker compose up -d

# Si vous construisez votre propre image, re-puller la base puis construire
docker compose build --pull

# Version dans un conteneur en cours d'exécution
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Remplacez app dans la dernière commande par le nom de votre propre service. Chaque image officielle est construite avec une seule PHP_VERSION ; la version CLI dans un conteneur correspond donc à la version FPM / Apache de ce conteneur (le piège 1 s'applique lorsque PHP est installé directement sur l'hôte).

FrankenPHP embarque PHP, si bien que la version de FrankenPHP et la version de PHP embarquée sont deux numéros différents. Les notes de version de FrankenPHP 1.13.2, publiée le 2026-10-21, indiquent que les images Docker ont été construites avec PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 et les binaires statiques avec PHP 8.5.12.

Piège 3 : les paquets de distribution sont « corrigés sous d'anciens numéros »

Ubuntu et RHEL ne portent que les correctifs vers les anciennes versions (backport). Le numéro affiché par php -v reste ancien : un contrôle numérique du type « inférieur à 8.3.36, donc vulnérable » signalera comme vulnérable un système pourtant corrigé. À l'inverse, on ne peut pas non plus se rassurer sur la base du numéro. Décidez d'après la version du paquet et le tracker de sécurité de chaque distribution.

Paquets corrigés listés dans chaque tracker au 2026-10-22 (identiques pour les deux CVE) :

Ce tableau montre directement pourquoi les numéros seuls ne suffisent pas. Le PHP corrigé d'Ubuntu 24.04 est une version commençant par 8.3.6, bien inférieure au 8.3.36 d'upstream. Le PHP par défaut de RHEL 9 est corrigé tout en restant en 8.0.30, alors qu'upstream ne publie plus de correctifs pour 8.0. Debian est passée aux mêmes numéros qu'upstream (8.2.35 / 8.4.27).

Certains paquets ne sont pas encore corrigés (au 2026-10-22).

• Le module php 8.4 de RHEL 9 est indiqué « affecté, pas de correctif ».
• Debian forky (testing) a php8.4 8.4.26-1, marqué « vulnerable ». Le php8.4 de sid (unstable) est en 8.4.27-1 et corrigé.

Exemples de commandes pour vérifier votre propre serveur :

# Debian / Ubuntu : version installée et version disponible
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu : cette CVE est-elle corrigée sur ce serveur
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Famille RHEL : existe-t-il une mise à jour corrigeant cette CVE, et version installée
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Adaptez le nom du paquet (php8.3-fpm, etc.) à votre environnement. Comparez la version affichée avec la « version corrigée » du tableau ci-dessus ou du tracker ; si elle est identique ou supérieure, le correctif est présent. Terminez ensuite par le redémarrage et la vérification côté web décrits au piège 1.

Si vous installez PHP depuis un dépôt tiers plutôt que depuis les paquets de la distribution, vous devez suivre les mises à jour de ce dépôt. L'avis de PHP précise que rpms.remirepo.net, géré par des bénévoles, n'aurait pas de mises à jour le jour de la divulgation, et recommande de passer aux paquets de la distribution ou à vos propres builds.

Piège 4 : sur un hébergement mutualisé ou un environnement géré, vous ne pouvez pas mettre PHP à jour vous-même

Sur les hébergements mutualisés et les environnements PHP gérés, c'est l'hébergeur qui remplace l'environnement d'exécution PHP. Là aussi, le numéro seul ne suffit pas : si l'hébergeur compile PHP lui-même ou rétroporte les correctifs, le numéro de version peut rester ancien.

Trois choses sont à votre portée.

1. Vérifier la version côté web. Utilisez le fichier temporaire du piège 1 pour afficher PHP_VERSION et PHP_SAPI, puis supprimez-le aussitôt. Si le panneau de contrôle propose un sélecteur de version de PHP, notez aussi la version que vous avez choisie.
2. Lire l'avis de l'hébergeur et, à défaut, lui poser la question. Demandez : « Pour quelles versions de PHP de mon offre les correctifs de CVE-2026-109618 et CVE-2026-109619 seront-ils appliqués, et quand (ou l'ont-ils été) ? » Poser la question avec le numéro de CVE plutôt qu'avec un numéro de version permet d'obtenir une réponse qui couvre aussi les backports.
3. Si vous avez choisi une version non prise en charge, passez à une version supérieure. Le projet PHP ne publie aucun correctif pour 8.1 et antérieures, et le support de 8.2 se termine le 2026-12-31. À moins que l'hébergeur n'ait rétroporté les correctifs, changer de version est la voie sûre.

État par hébergeur (au 2026-10-22)

Sur un hébergement mutualisé, c'est normalement l'hébergeur qui met à jour l'environnement PHP, et les avis de nombreux fournisseurs indiquent qu'« aucune action n'est requise de la part des utilisateurs ». Il vous reste deux choses à faire : consulter l'avis officiel de votre hébergeur et, si vous avez sélectionné une ancienne version de PHP dans le panneau de contrôle, décider de passer ou non à la version recommandée par l'avis (une version pour laquelle un correctif a été publié).

Le tableau ci-dessous résume uniquement ce qui est écrit sur les pages officielles de chaque hébergeur (annonces et informations de maintenance), en paraphrasant la formulation de leurs avis. Les avis sont mis à jour au fil de l'avancement ; vérifiez donc toujours l'état réel sur la page officielle citée.

Lorsque je n'ai pas pu trouver ou ouvrir un avis officiel, le tableau indique « non confirmé » ou « introuvable ». L'absence d'information ne signifie pas que l'hébergeur n'a pas réagi. Vérifiez directement auprès des annonces et du support de votre hébergeur.

Mesures d'atténuation tant que vous ne pouvez pas mettre à jour immédiatement

L'avis de PHP liste des réglages qui réduisent la surface d'attaque jusqu'à la mise à jour. Toutefois, l'avis lui-même précise explicitement qu'ils « ne vous rendent pas sûr ». Les principaux sont :

• Pour CVE-2026-109619 : définir session.upload_progress.enabled=0 dans php.ini, dans le pool FPM ou dans la configuration du serveur, puis redémarrer tous les workers (ini_set() et le .user.ini de FPM n'ont pas d'effet ici). Sur PHP 8.5, définir aussi fatal_error_backtraces=0.
• Pour CVE-2026-109618 : définir memory_limit=-1 de manière que l'application ne puisse pas le modifier, et réduire post_max_size (8M s'il n'y a pas d'envois de fichiers, 32M s'il y en a). Ne pas utiliser RLIMIT_AS / RLIMIT_DATA comme substitut.

Le NCSC britannique recommande d'envisager de mettre hors ligne tout système qui ne peut être ni mis à jour ni atténué immédiatement, et de rechercher des signes de compromission avant la mise à jour ou l'application des mesures d'atténuation.

Sources (consultées le 2026-10-22)

• php.net : Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net : Upcoming Critical PHP Security Release (2026-10-20)
• php.net : annonces de publication de PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub : GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub : GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub : image officielle php
• Notes de version de FrankenPHP 1.13.2
• Debian Security Tracker : CVE-2026-109618 / CVE-2026-109619
• Ubuntu : CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat : CVE-2026-109618 / CVE-2026-109619 (versions des paquets corrigés issues des données VEX de Red Hat)
• NCSC : Critical security issue affecting PHP