En bref : sur RHEL, AlmaLinux et Rocky Linux, vous vérifiez le correctif PHP contre PHP2Shell par trois voies : les avis de sécurité de la distribution (dnf updateinfo), le changelog du paquet (rpm -q --changelog) et l'heure de démarrage des processus PHP. Red Hat indique RHEL 7 à 10 comme concernées et signalait lors de la consultation que certaines mises à jour étaient disponibles et d'autres en cours. Après la mise à jour : redémarrer complètement, et non seulement recharger.
Ce que Red Hat a publié sur PHP2Shell
Red Hat a publié sur PHP2Shell le bulletin de sécurité RHSB-2026-013. Nous l'avons consulté le 25 octobre 2026. Les points les plus importants pour les admins :
- Sont concernés RHEL 10, 9, 8 et 7 ainsi que les produits qui en dépendent et les conteneurs reposant sur des images RHEL ou UBI.
- RHEL 7 n'est, selon Red Hat, concernée que par CVE-2026-109619 ; le code de CVE-2026-109618 n'y serait pas présent.
- Ne sont pas concernés les systèmes sans PHP ou dont PHP ne traite pas de requêtes HTTP non fiables.
- Mises à jour : certaines étaient disponibles lors de la consultation, d'autres en cours. Le bulletin ne citait pas de numéros d'errata concrets, mais renvoyait aux pages d'errata.
Red Hat évalue CVE-2026-109618 avec sa propre méthode comme « Important » et souligne que les installations par défaut à partir de RHEL 8 utilisent PHP-FPM plutôt que mod_php. C'est un classement, non une fin d'alerte. Le projet PHP évalue les deux failles à CVSS v4.0 9,2, et le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande la mise à jour immédiate.
AlmaLinux et Rocky Linux : même source, rythme propre
AlmaLinux et Rocky Linux reconstruisent leurs paquets à partir des sources de Red Hat. Les corrections arrivent donc en règle générale identiques sur le fond, mais à leur propre moment et sous leurs propres avis de sécurité. L'indication d'un errata Red Hat ne signifie pas que le paquet est disponible le même jour chez votre dérivé.
Ce qui est décisif, c'est donc le niveau sur votre système. Vérifiez-le avec les outils de gestion des paquets, et non d'après des actualités ou des forums.
Veillez en outre à savoir si le serveur utilise des serveurs miroirs ou des sources de paquets internes. Dans de nombreuses entreprises, les serveurs n'obtiennent pas leurs mises à jour directement chez l'éditeur, mais via un miroir interne ou un outil de gestion. Si ce miroir n'est pas à jour, dnf ne trouve pas de nouveaux paquets, alors qu'ils sont publiés depuis longtemps.
Vérifier le correctif PHP sur RHEL et dérivés
Les commandes suivantes sont en lecture seule. Les noms de paquets valent pour les paquets PHP de la distribution ; les paquets de sources tierces comme Remi portent parfois d'autres noms.
# Quels flux PHP le système connaît-il, lequel est actif ? (RHEL 8 et 9)
dnf module list php
# Paquets PHP installés avec version et origine
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Existe-t-il des avis de sécurité pour les CVE pour ce système ?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# La correction figure-t-elle dans le changelog du paquet installé ?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo n'affiche que les avis pour les mises à jour pas encore installées ; avec --installed, vous voyez aussi celles déjà appliquées. Un résultat vide peut donc signifier deux choses : la mise à jour est déjà installée ou pas encore publiée. La comparaison avec le changelog tranche. La manière de consigner le résultat comme preuve est décrite dans l'article Prouver les numéros CVE dans le changelog du paquet.
Comme pour d'autres distributions d'entreprise, le paquet conserve le plus souvent sa version d'origine de PHP ; seule l'indication de release change. Un numéro plus ancien avec php -v n'est donc pas un indice d'une correction manquante. Des indications générales sur la vérification des versions figurent sous Bien vérifier la version de PHP et le niveau de correctif.
Reconnaître le bon mode d'exécution
Red Hat cite les modes d'exécution par défaut : à partir de RHEL 8, PHP fonctionne via PHP-FPM, sur RHEL 7 comme mod_php dans le service Apache httpd. De nombreux serveurs s'en écartent, par exemple à cause de panneaux, de sources tierces ou d'anciennes configurations.
| Système | Par défaut selon Red Hat | Redémarrage après la mise à jour |
|---|---|---|
| RHEL 8, 9, 10 et dérivés | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php dans httpd | systemctl restart httpd |
| Conteneurs sur base RHEL ou UBI | selon l'image | reconstruire l'image, remplacer le conteneur |
Pour les conteneurs, Red Hat recommande de reconstruire ses propres images après des images de base mises à jour et de remplacer les conteneurs ou pods en cours. Une mise à jour dans le conteneur en cours d'exécution n'est pas une voie fiable.
Après la mise à jour : redémarrage et contrôle
Red Hat souligne qu'un rechargement ne suffit pas. Les workers existants peuvent conserver l'état concerné. Redémarrez donc chaque service qui charge PHP et contrôlez le résultat :
# Afficher les services avec des bibliothèques obsolètes (dnf-utils ou dnf-plugins-core)
needs-restarting -s
# Comparer l'heure de démarrage des processus PHP avec le moment de la mise à jour
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Pour la configuration, Red Hat donne une indication pratique : php -i affiche les paramètres de la ligne de commande, non ceux du serveur web. Qui veut vérifier si des valeurs transitoires comme session.upload_progress.enabled=0 s'appliquent dans le contexte web utilise brièvement une page phpinfo protégée et la supprime ensuite. Ce qu'il faut observer d'autre lors du redémarrage figure sous Redémarrer PHP-FPM et tous les workers.
Mesures transitoires : les indications de Red Hat
Là où une mise à jour manque encore, Red Hat renvoie aux mêmes mesures transitoires que php.net et ajoute quelques indications pratiques pour les systèmes RHEL. Elles ne remplacent pas la mise à jour.
- Vraiment ajouter la ligne : selon Red Hat, la ligne pour
session.upload_progress.enabledest commentée dans la configuration livrée, la fonction est donc active par défaut. La valeur0doit être définie expressément. - Définir de façon non écrasable : via
php_admin_valuedans le pool PHP-FPM, avec mod_php dans la configuration d'Apache. Pas viaini_set()ni.user.ini. - Chercher les contre-forces : Red Hat recommande de vérifier si des fichiers
.htaccess, des VirtualHosts et des fichiers.user.iniréactivent les paramètres concernés. - Poser aussi des limites en amont : outre
post_max_sizedans PHP, Red Hat conseille d'envisager des limites de taille des requêtes dans le serveur web ou le proxy.
Sur les systèmes PHP-FPM, les pools se trouvent en règle générale sous /etc/php-fpm.d/. Après chaque modification, la même règle s'applique qu'après la mise à jour : redémarrer complètement tous les workers.
Si du PHP du dépôt Remi tourne en plus sur le même serveur, des paquets et services propres s'appliquent. Lisez à ce sujet l'article Le dépôt Remi.
Comment PHP SOS aide-t-il concrètement ?
- Sur RHEL, AlmaLinux et Rocky Linux, nous vérifions tous les paquets PHP, flux et sources tierces et les recoupons avec les avis de sécurité.
- Nous installons les mises à jour, redémarrons complètement tous les workers et contrôlons les heures de démarrage des processus.
- Pour les environnements de conteneurs, nous reconstruisons les images et remplaçons les instances en cours de façon contrôlée.
- Nous consignons l'état de chaque serveur dans la preuve du service de correctifs PHP.
Questions fréquentes
RHEL 7 est-elle concernée par PHP2Shell ?
Selon Red Hat, RHEL 7 n'est concernée que par CVE-2026-109619 ; le code vulnérable pour CVE-2026-109618 n'y serait pas présent. Sur RHEL 7, mod_php est le mode d'exécution par défaut, que l'équipe PHP juge particulièrement risqué.
Pourquoi Red Hat évalue-t-elle la faille plus bas que php.net ?
Red Hat utilise sa propre évaluation selon CVSS v3.1 et classe CVE-2026-109618 comme Important, car l'exploitation exigerait un timing précis. php.net évalue à CVSS v4.0 9,2. Les deux jugent possible l'exécution de code sans authentification ; la mise à jour est de toute façon nécessaire.
AlmaLinux et Rocky Linux reçoivent-ils les corrections automatiquement ?
Tous deux reconstruisent leurs paquets à partir des sources de Red Hat et publient leurs propres avis de sécurité. Le moment peut différer de celui de Red Hat. Vérifiez donc le niveau sur votre propre système et dans les avis de votre distribution.
systemctl reload php-fpm suffit-il après la mise à jour ?
Non. Red Hat souligne expressément qu'un rechargement ne suffit pas, car les workers existants peuvent conserver l'état concerné. Redémarrez tous les workers, avec mod_php le service Apache httpd.