Le projet PHP a annoncé deux vulnérabilités permettant toutes deux une exécution de code à distance sans authentification : un attaquant peut exécuter du code sur le serveur sans aucun identifiant. Les deux sont classées critiques, avec un score CVSS de 9,2.

CVE-2026-109618 concerne la gestion du manque de mémoire : PHP peut s'interrompre au milieu de la préparation d'une requête et laisser des données internes à moitié initialisées, ensuite traitées comme valides. CVE-2026-109619 concerne un état qui survit à la requête : un appel ultérieur traité par le même processus peut accéder à des données dont la mémoire a déjà été libérée.

Les deux sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si vous êtes sur l'une de ces versions, le sujet est clos.

Cette faille n'a rien à voir avec votre code. Elle se situe dans la couche qui l'exécute, et elle agit avant qu'une seule ligne de votre application ne tourne.

Selon l'advisory, tout ce qui traite des requêtes web est concerné : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque le plus élevé concerne mod_php, où il a été démontré qu'une seule requête non authentifiée peut déclencher l'attaque avant l'exécution du code applicatif.

C'est ce qui distingue cette annonce de la plupart des autres. Que votre serveur fasse tourner Contao, WordPress, Shopware ou un développement sur mesure n'a aucune importance. Que vos formulaires valident correctement les entrées n'en a pas davantage. C'est la couche inférieure qui est attaquée.

À l'inverse, cela signifie qu'il n'y a rien à corriger dans votre application. La seule solution complète est la mise à jour.

Aucune ne demande un développeur. Votre hébergeur peut répondre à toutes – et s'il tarde, cela vous apprend aussi quelque chose.

• Quelle version de PHP tourne sur chacun de vos sites ? Non pas celle que vous croyez, mais celle qui est réellement servie. Et par site, pas par serveur : plusieurs versions cohabitent souvent sur un même hébergement.
• Est-elle déjà corrigée ? Les versions de référence sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ou ultérieures. Un numéro majeur plus élevé ne suffit pas : 8.4.20 est plus récente que 8.3.36 et reste vulnérable.
• Qui applique la mise à jour, et quand ? En hébergement infogéré, c'est le prestataire : demandez une date, pas une intention. Sur vos propres serveurs, c'est vous. Les distributions Linux ont reçu les correctifs en avance, le paquet est souvent déjà disponible.
• Reste-t-il des systèmes auxquels plus personne ne pense ? Un ancien environnement de test, un sous-domaine d'il y a trois ans, le portail client d'un projet arrêté. Accessible reste accessible. Ce sont ces systèmes-là qui servent de porte d'entrée, pas le site principal que tout le monde surveille.

PHP 8.1, 8.0 et 7.4 ne reçoivent plus de mises à jour régulières du projet. Des rétroportages minimaux existent pour ces deux failles précises, mais c'est une mesure d'urgence, pas une solution : à la prochaine annonce, vous serez au même point. La branche 8.2 s'arrête elle aussi au 31 décembre 2026.

C'est là que cela devient inconfortable pour une entreprise de notre taille. Dans une maison de quarante personnes, il existe presque toujours une application qui tourne depuis des années, que plus personne ne suit et dont le prestataire d'origine est injoignable. Tant que rien n'arrive, elle ne coûte rien. Un jour comme celui-ci, elle devient le système le plus cher de la maison.

Chez nous, la journée s'est déroulée ainsi : lecture de l'advisory, revue de tous nos systèmes, puis passage de l'ensemble des sites que nous hébergeons aux versions corrigées. Ce n'est pas un exploit, c'est la normale – reste à savoir si quelqu'un en a la charge.

Une annonce à 9,2 pousse à prendre des décisions de fond. Nous le déconseillons, du moins cette semaine.

• Ne lancez pas une migration que vous n'aviez pas prévue. Mettre à jour une version de PHP prend des heures. Remplacer un système prend des mois. Mélanger les deux, c'est se retrouver dans un mois encore sur la version vulnérable, avec un chantier en plus.
• Ne changez pas de prestataire parce qu'il n'a pas encore corrigé. Demandez d'abord une date. Un hébergeur qui met à jour en quelques jours travaille normalement. Celui qui ne répond pas précisément à une question précise est le vrai problème – et il l'était déjà avant cette faille.
• Ne vous reposez pas sur les contournements. L'advisory propose des configurations qui réduisent la surface d'attaque lorsqu'une mise à jour est impossible à court terme. Il précise explicitement qu'elles ne rendent pas l'installation sûre. Acceptable pour tenir un week-end, pas comme état durable.

• PHP.net – Sicherheitswarnung vom 21. Oktober 2026
• CVE-2026-109618 – RCE durch OOM-Korruption (GHSA-w8hw-w9fx-j79w)
• CVE-2026-109619 – RCE durch veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp)
• PHP – Downloads und unterstützte Versionen