2 Failles critiques dans PHP : ce que vous devez faire sans attendre

L’annonce est tombée mardi soir sur php.net. L’équipe de sécurité de PHP y prévient d’une release de sécurité programmée le mercredi 21 octobre 2026 à 14:00 UTC, qui corrige deux vulnérabilités critiques, toutes deux notées 9,2 sur l’échelle CVSS v4.0. Aucun détail technique n’est donné, car les versions affectées, les versions corrigées et la nature des failles ne seront publiées qu’avec le correctif. PHP demande à tous ses utilisateurs de se préparer dès maintenant, et se réserve le droit de publier plus tôt si les détails fuitent ou si une exploitation est repérée. La PHP Foundation a relayé l’avertissement sur X dans la foulée.

Que sait-on vraiment des deux failles critiques de PHP ?

Peu de choses, et c’est voulu. Les chercheurs de watchTowr affirment de leur côté que les deux failles permettent l’exécution de code à distance, ce que PHP n’a pas confirmé. Les identifiants CVE-2026-109618 et CVE-2026-109619 qui circulent viennent d’une fuite publiée mardi sur Hacker News, que PHP ne reprend pas dans son annonce. Cette fuite évoquait aussi toutes les versions depuis PHP 5 : la FAQ de watchTowr précise que cette portée n’est confirmée par aucun avis officiel.

Au 21 octobre, aucune exploitation n’est signalée et les failles ne figurent pas dans le catalogue des vulnérabilités exploitées de la CISA. Des chercheurs ont quand même trouvé le temps de baptiser le duo « php2shell » (le nom est le leur, pas celui de PHP).

Quelles versions de PHP recevront le correctif ?

Seules les quatre branches encore supportées, de 8.2 à 8.5, recevront le correctif. Les versions en fin de vie (8.1,8.0,7.x, 5.x) ne recevront rien de la part de PHP. Vous verrez sans doute passer les numéros 8.5.12,8.4.27,8.3.36 et 8.2.35 : ils circulent chez plusieurs trackers, mais PHP ne les a pas confirmés.

Source : The Hacker News, d’après php.net

Et le parc ancien n’a rien de marginal. La société Mallory a compté environ 884 000 hôtes exposés sur Internet dont la bannière HTTP annonçait PHP 8.1 ou plus ancien, soit 59 % des hôtes affichant une version. Il s’agit de bannières, pas de systèmes dont la vulnérabilité est confirmée.

Docker et FrankenPHP : le plan pas à pas pour redéployer PHP corrigé

Dans un conteneur, PHP vient de l’image. Tant que l’image de base n’a pas été reconstruite avec la version corrigée, votre déploiement embarque l’ancienne. Mak (@MakTwenty) a publié sur X un plan pas à pas pour une stack PHP 8.4 sous FrankenPHP.

À 16h, il prévoit de vérifier que la 8.4 corrigée est sortie, puis d’attendre que l’image FrankenPHP soit reconstruite. Il récupère ensuite le nouveau digest avec docker buildx imagetools inspect et le monte en production et en développement : Mak insiste sur ce « ET ». Viennent ensuite le rebuild, un php -v dans le conteneur pour vérifier la version, la CI, le déploiement et un health-check de l’API.

Côté FrankenPHP, le projet indique sur sa page de sécurité que ses binaires et ses images Docker sont reconstruits chaque nuit avec les dernières versions des dépendances, et que seule la dernière version est supportée. Le sujet n’est pas théorique pour le projet : en février 2026, il avait d’ailleurs publié un avis critique sur la propagation tardive des correctifs de sécurité des images de base amont. D’où l’intérêt du php -v dans le plan de Mak : vérifier soi-même la version embarquée plutôt que de supposer qu’elle est à jour.

Quels services PHP vérifier avant le correctif ?

Tous ceux qui exécutent du PHP, y compris ceux qu’on oublie facilement. Mak insiste sur les services annexes, comme Laravel, les workers ou Mercure, qui partagent souvent la même image que l’application principale. Le front et les services Node ou Python ne sont pas concernés. Sa consigne tient en une phrase : « Faites l’inventaire avant 16h. » Huntress va dans le même sens et conseille de recenser chaque installation, y compris le PHP embarqué dans des appliances, des logiciels Windows ou des panneaux comme cPanel et Plesk.

Images serversideup/php : Jay Rogers attend les images officielles de PHP

Mak attribue le signalement à Jay Rogers (@jaydrogers), qui maintient les images Docker serversideup/php, dont une variante FrankenPHP. Dès mardi soir, il annonçait sur X un correctif « tomorrow at 10 AM EDT », soit 14h UTC, et promettait de publier les mises à jour de serversideup/php dès que les images seraient construites. Interrogé par un utilisateur sur GitHub, Jay Rogers a répondu qu’il était « already on top of it » et qu’il mettrait à jour ses images dès que les images Docker officielles de PHP seront construites.

Si vous ne pouvez pas patcher tout de suite, le CERT-EU conseille d’envisager d’isoler les applications exposées sur Internet jusqu’à ce qu’un correctif soit disponible. L’utilisateur qui interrogeait Jay Rogers sur GitHub hésitait justement à couper son système, en rappelant que c’est de l’argent perdu.