Vulnérabilités PHP critiques CVE-2026-109618 et CVE-2026-109619 : ce qu'il faut savoir

Le 21 octobre 2026, l'équipe de sécurité de PHP a publié les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Toutes deux obtiennent un score CVSS v4.0 de 9,2 et peuvent conduire à une exécution de code à distance sans authentification sur toute installation PHP qui traite des requêtes web. L'équipe PHP considère mod_php comme le déploiement le plus à risque : un exploit démontré s'y déclenche avant même l'exécution du moindre code applicatif. La mise à jour est la seule correction complète. Red Sift a analysé l'ensemble de la base clients Hardenize pour identifier les hôtes reposant sur PHP et a directement prévenu les clients concernés.

• Toutes les versions de PHP depuis PHP 5 sont potentiellement concernées, que ce soit avec PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ou LiteSpeed.
• PHP 8.1 et les versions antérieures ne bénéficient d'aucune version officielle corrigée. Utilisez un rétroportage fourni par votre éditeur, les correctifs source publiés par l'équipe PHP pour les branches 7.4, 8.0 et 8.1, ou effectuez une montée de version.
• Les modifications de configuration réduisent l'exposition aux vecteurs d'attaque connus, mais ne suffisent pas à sécuriser une installation.
• PHP est souvent intégré à des appliances et à des produits tiers : vérifier la version sur vos propres serveurs ne donne donc qu'une vision partielle.

PHP fait tourner une grande partie du web côté serveur, des systèmes de gestion de contenu jusqu'aux interfaces d'administration des équipements réseau. Une faille permettant à une requête anonyme d'exécuter du code dans le moteur PHP lui-même, indépendamment de l'application qui s'appuie dessus, a une portée parmi les plus larges qui soient pour une vulnérabilité web.

L'équipe PHP a émis un préavis le 20 octobre et publié les correctifs dès le lendemain. Les CERT nationaux ont réagi rapidement. Le CERT-EU a demandé aux organisations de se préparer à appliquer les correctifs immédiatement et d'envisager d'isoler les applications PHP exposées sur Internet en attendant. Au Royaume-Uni, le NCSC a appelé les organisations à agir sans délai, en commençant par recenser tous les systèmes qui exécutent PHP.

Les deux failles se situent dans la façon dont PHP gère l'état propre à chaque requête au sein d'un worker, et non dans le code applicatif.

• CVE-2026-109618, RCE via une corruption liée à un manque de mémoire (GHSA-w8hw-w9fx-j79w). Une condition de manque de mémoire (OOM) peut interrompre PHP alors que des données internes de la requête ne sont que partiellement initialisées. Le nettoyage de la requête traite ensuite ces données incomplètes comme valides, ce qui corrompt la mémoire. Dans certaines conditions, un attaquant capable de pousser une requête dans ce chemin OOM peut exploiter cette corruption pour exécuter du code.
• CVE-2026-109619, RCE via un état global obsolète (GHSA-6wmf-4rv5-p3rp). Un état interne appartenant à une requête peut survivre à la mémoire qui le contient. Une requête ultérieure traitée par le même worker peut alors utiliser cet état obsolète avant que l'initialisation normale ne le réinitialise, ce qui entraîne un use-after-free d'une requête à l'autre.

La seconde faille concerne surtout les workers de longue durée, mode de fonctionnement de PHP-FPM, mod_php et FrankenPHP. L'équipe PHP considère mod_php comme la configuration la plus à risque, car l'exploit démontré se déclenche pendant l'analyse de la requête, avant même que votre application ne la reçoive. Une règle de pare-feu applicatif web (WAF) liée aux routes de l'application ne la bloquera pas.

Toute installation PHP qui traite des requêtes web est concernée. Cela inclut PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le CERT-EU indique que toutes les versions depuis PHP 5 peuvent être affectées : un numéro de version ancien n'est donc pas une raison de reléguer un hôte au second plan. C'est au contraire une raison de le traiter en priorité, puisque PHP 8.1 et les versions antérieures ne recevront pas de paquet officiel.

Le plus difficile, c'est le PHP que vous n'avez pas installé vous-même. Les appliances, les services hébergés et les applications tierces embarquent souvent PHP comme composant interne. Ces produits ne sont corrigés que lorsque leur éditeur publie une mise à jour. Le NCSC-NL tient à jour un inventaire des logiciels dépendant de PHP susceptibles d'être affectés, un bon point de départ pour cette partie de la recherche.

Avant la publication des versions PHP corrigées, nous avons analysé les hôtes que nous surveillons pour l'ensemble des clients Hardenize afin d'identifier ceux qui exécutent PHP. Nous avons ensuite rattaché ces hôtes à chaque client et contacté directement toutes les organisations concernées en leur fournissant la liste des noms d'hôtes potentiellement exposés, l'heure de publication et les liens vers les avis officiels. Les équipes ont ainsi pu mesurer leur exposition avant la sortie des versions corrigées et planifier des fenêtres de maintenance, au lieu de commencer l'inventaire après la publication.

Si vous êtes client Hardenize et que vous n'avez pas reçu de notification, c'est que nous n'avons pas détecté PHP sur les hôtes que nous surveillons pour vous. Nous vous conseillons néanmoins d'effectuer quelques vérifications de votre côté. Une analyse externe ne voit que ce qu'un hôte laisse paraître et ne couvre que les actifs de votre compte. Il vous revient de vérifier vos systèmes internes, les hôtes situés hors du périmètre surveillé et les produits qui masquent leur moteur PHP.

Si vous êtes concerné, appliquez les correctifs dès que possible partout où vous le pouvez. Toutes les mesures de cette liste s'adressent aux hôtes que vous ne pouvez pas corriger aujourd'hui.

• Recensez toutes les installations PHP, en commençant par les hôtes exposés sur Internet. Ne filtrez pas par version, puisque toutes les versions peuvent être concernées. Incluez les conteneurs, les images de base et tout ce qui est compilé à partir des sources.
• Passez à une version corrigée. Migrez vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installez le paquet corrigé de votre distribution. Les distributions Linux et les fournisseurs LTS ont reçu les correctifs en avance. Si vous utilisez rpms.remirepo.net, l'équipe PHP recommande de passer aux paquets de votre distribution ou de compiler à partir des sources, car ce dépôt n'a pas proposé de mises à jour le jour même.
• Traitez les branches en fin de vie. Sur 8.1 et les versions antérieures, utilisez un rétroportage de votre éditeur, compilez à partir des rétroportages source de l'équipe PHP pour 7.4, 8.0 ou 8.1, ou effectuez une montée de version.
• Redémarrez tous les workers. Un binaire corrigé ne change rien pour les pools FPM ou les processus enfants Apache qui exécutent encore l'ancien code.
• Traquez le PHP embarqué. Consultez les avis des éditeurs pour les appliances et produits qui intègrent PHP, et appliquez leurs mises à jour dès leur disponibilité.
• Atténuez ou isolez ce que vous ne pouvez pas corriger. Appliquez les mesures provisoires ci-dessous. Si ce n'est pas possible, le CERT-EU et le NCSC recommandent tous deux de mettre hors ligne l'application exposée sur Internet jusqu'à sa correction.
• Recherchez des signes de compromission sur les hôtes restés exposés. Le NCSC recommande de rechercher d'éventuelles portes dérobées avant ou pendant la remédiation sur tout système que vous n'avez pas pu mettre à jour rapidement.

• Définissez memory_limit=-1 de façon que les applications ne puissent pas le modifier, par exemple avec php_admin_value dans le pool FPM ou la configuration Apache. Assurez-vous qu'aucun paramètre de pool, de répertoire ou d'application ne réintroduit une limite finie. Un échec d'allocation sous-jacent peut néanmoins toujours atteindre le chemin vulnérable.
• Abaissez post_max_size à 8M lorsque les téléversements ne sont pas nécessaires, ou à 32M lorsqu'ils le sont, et maintenez upload_max_filesize en dessous de cette valeur. Imposez au niveau du serveur web ou du proxy des limites sur la taille des requêtes, le nombre de champs, le nombre de parties multipart, le nombre d'en-têtes et la profondeur d'imbrication, y compris pour les requêtes sans Content-Length exploitable.
• Utilisez une limite mémoire de conteneur ou de cgroup qui n'arrête que le worker concerné. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA, qui peuvent provoquer l'échec d'allocation vulnérable.

• Définissez session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration du serveur, puis redémarrez tous les workers. ini_set() et .user.ini s'appliquent trop tard pour être utiles.
• Sur PHP 8.5, définissez fatal_error_backtraces=0 et redémarrez tous les workers.
• Supprimez les paramètres par requête invalides ou obsolètes qui émettent des diagnostics avant l'initialisation. Masquer la sortie avec error_reporting, display_errors ou @ ne sert à rien.
• Corrigez les erreurs fatales et les dépassements de délai d'exécution qu'un attaquant peut déclencher, y compris dans les callbacks, le traitement des téléversements ou des imports, et les phases de nettoyage.

Ces mesures bloquent les vecteurs d'attaque confirmés, mais pas toutes leurs variantes. Considérez-les comme une solution transitoire en attendant l'application des correctifs.

La première consigne des avis du CERT-EU et du NCSC est la même : identifier où PHP s'exécute. Pour la plupart des équipes, c'est l'étape la plus lente, car la réponse est dispersée entre comptes cloud, domaines issus d'acquisitions, sites marketing et appliances d'éditeurs que personne n'a répertoriés.

Red Sift Hardenize découvre et surveille en continu vos actifs exposés sur Internet et dans le cloud. Ainsi, lorsqu'une vulnérabilité de ce type touchant un moteur d'exécution est découverte, la liste des hôtes exposés existe déjà. C'est ce qui nous permet de prévenir nos clients en leur indiquant des noms d'hôtes précis avant même la publication des versions corrigées.

• Avis de sécurité et annonces de publication de PHP, 20 et 21 octobre 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• Avis de sécurité CERT-EU 2026-018
• NCSC, Problème de sécurité critique affectant PHP
• Inventaire php2shell du NCSC-NL des logiciels concernés