Failles PHP CVE-2026-109618 et CVE-2026-109619

Comment l’équipe Hosting chez Codéin a géré l’application des patchs de sécurité PHP sur son parc

Le contexte

Le Hosting Codéin gère environ 300 serveurs Linux. La grande majorité de ces serveurs hébergent des applications web propulsées par le langage PHP. Lorsque l’équipe arrive le matin du 21 octobre 2026 au bureau et prend connaissance des failles CVE-2026-109618 et CVE-2026-109619, elle s’attend donc à une journée mouvementée !

Le contexte : deux failles critiques PHP allaient être dévoilées le jour même, avec un patch de sécurité mis à disposition à 16H. L’exploitation de ces failles seraient triviales et permettraient d’exécuter du code à distance sur les serveurs. Toutes les versions de PHP depuis l’antique 5.4 sont concernées.

Les développeurs PHP ont annoncé des patchs de sécurité pour les versions 8.2 à 8.5.

L’importance du choix d’une distribution supportée

Il y a deux choses différentes à bien comprendre en matière de sécurité sur les composants installés sur un serveur Linux (avec comme exemples la distribution Ubuntu et le langage PHP) :

• le support de sécurité du composant en lui même : les développeurs PHP (qu’on peut appeler “l’upstream”) supportent les versions 8.2 (dont le support s’arrêtera en décembre 2026) jusqu’à 8.5 (dont le support s’arrêtera en décembre 2029), d’où l’annonce initiale faite par PHP
• le support de sécurité de la distribution Linux utilisée : si vous installez PHP sur Ubuntu de manière standard  (miroirs Ubuntu et outil apt) , vous n’installez pas directement un PHP fourni par les développeurs PHP, mais vous installez un paquet créé et maintenu par Ubuntu. Ubuntu est garant de l’application des patchs de sécurité sur le PHP qu’ils fournissent. Ubuntu garantit également, qu’au sein d’une même version de sa distribution (par exemple, 22.04 ou 24.04), la version de PHP proposée ne bougera pas durant toute la durée de support de la distribution (c’est ce qu’on appelle une distribution “stable”)

Cela signifie concrètement qu’en 2022, lorsqu’on installe Ubuntu 22.04 avec PHP 8.1 (version proposée sur les miroirs officiels), notre client sait que son application web pourra tourner jusqu’en 2027 (Ubuntu propose par défaut des durées de support de 5 ans, comme Debian) sans nécessité de passer sur une nouvelle version de PHP (ce qui peut être compliqué en fonction de la complexité de l’application) mais tout en bénéficiant d’un support de sécurité, même si le support officiel par PHP (l’upstream) s’arrête.

C’est pour cela qu’au Hosting Codéin, par défaut, nous ne proposons que les composants issus de la distribution utilisée. C’est un gage de stabilité et de sérénité pour nos clients et pour nous.

Le matin du 21 octobre 2026, nous savions donc que l’ensemble des distributions suivantes, toujours supportées, allaient bénéficier d’un patch, qu’importe la version de PHP installée : 

• Ubuntu 22.04 (PHP 8.1, théoriquement non patchée par PHP lors de l’annonce initiale)
• Ubuntu 24.04 (PHP 8.2)
• Ubuntu 26.04 (PHP 8.5)
• Debian 12 (PHP 8.3)
• Debian 13 (PHP 8.4)

Nous avons alors envoyé un premier message global à tous nos clients indiquant que les serveurs avec les distributions citées seraient mises à jour, mais que les serveurs avec des distributions plus anciennes ne bénéficieraient d’aucun patch.

L’application du patch sur les distributions supportées

L’utilisation de distributions stables et supportées nous permet d’installer quotidiennement et automatiquement l’ensemble des patchs de sécurité proposée sur les composants installés.

Cela signifie que nous aurions très bien pu attendre le lendemain ce processus automatique.

Compte tenu de l’ampleur de la faille annoncée, nous avons décidé de forcer l’installation du correctif dès que celui-ci serait disponible, à 16H.

L’ensemble de notre parc de serveurs est géré en Infrastructure as Code via l’outil Ansible. Nous nous servons également de Netbox (une base de données qui recense l’intégralité de nos serveurs avec notamment l’information de la version de la distribution utilisée) comme source de vérité unique.

Nous avons donc fait un inventaire des serveurs avec une distribution supportée et créé un script Ansible (un playbook) qui force la mise à jour de PHP.

Nous avons joué ce playbook dès que les distributions ont fourni les paquets PHP avec la faille corrigée. À 17H, l’ensemble de nos serveurs supportés était corrigé (environ 250).

Quid des serveurs avec des distributions obsolètes ?

Nous prévenons nos clients un an avant la fin du support de la distribution. Il arrive, pour des raisons diverses, que nos conseils de migration vers la version N+1 ne soient pas suivis. Nous prévenons bien que dans ce cas, aucun patch de sécurité de quelque sorte ne pourra être installé sur le serveur.

Nous avons donc encore quelques serveurs en Ubuntu 20.04 (PHP 7.4), Debian 11 (PHP 7.4) ou même Debian 9 et 10.

Comme je l’ai précisé plus haut, nous avons commencé par annoncer à nos clients que ces serveurs ne bénéficieraient d’aucun patch. Cependant, à 17H, après la gestion des serveurs sous support, nous avons constaté que le dépôt “Surý” a été mis à jour.

Ondřej Surý est un mainteneur officiel de paquets Debian bien connu des administrateurs système depuis de nombreuses années. Il réalise le travail parlé plus haut, en proposant des versions de PHP stables dans le temps avec les correctifs de sécurité associés sur les miroirs officiels de Debian.

En parallèle, il propose également, sur sa propre infrastructure (https://sury.org/), des versions de PHP compilées pour Debian et Ubuntu. La différence avec les paquets officiels réside en la possibilité d’installer des versions différentes de PHP (plus anciennes ou plus récentes) sur des versions différentes de Debian et Ubuntu et de ne pas être contraint par la stabilité de la distribution.

Sur son dépôt, Ondřej Surý a donc proposé des versions de PHP (de 5.6 jusqu’à 8.5 !) avec les failles critiques corrigées.

Par défaut, nous ne proposons pas de dépôt externe. Le dépôt Surý fait toutefois partie des rares cas où l’on peut faire une exception quand une distribution ne nous permet pas d’installer exactement la version nécessaire pour le projet et que c’est un point bloquant pour l’application.

Ce jour-là, nous avons donc décidé de passer l’intégralité des serveurs sous Debian 11 (la dernière version pour laquelle des paquets étaient proposés) sous le dépôt Surý afin de bénéficier d’un patch de sécurité pour PHP 7.4.

Nous avons utilisé les mêmes outils que pour la précédente vague de serveurs avec notamment la réalisation d’un inventaire ciblé tiré de Netbox et la réalisation d’un playbook Ansible. À 18H, les PHP 7.3 et 7.4 étaient également patchés grâce au miroir de paquets Surý (un grand merci à lui !).

Cas des serveurs à la marge

Après cette double passe, il restait 5 serveurs problématiques. Ces serveurs étaient dans des versions trop anciennes pour bénéficier d’une quelconque solution applicable immédiatement.

Les clients concernés ont été contactés et nous avons proposé des solutions adaptées à chacun. Nous avons par exemple proposé des mises à jour de la distribution en urgence vers des versions pouvant accepter les dépôts Surý. L’opération n’est toutefois pas sans risque, il peut y avoir des incompatibilités sur d’autres composants que PHP lors du passage à une version supérieure.

Certains clients ont accepté de mettre en maintenance leur site le temps de réaliser cette mise à jour.

Reste également le cas des serveurs ou infrastructures qui font tourner des containers (infrastructure Kubernetes, container Docker directement sur la machine virtuelle…). La majorité du temps, ces containers sont construits par les développeurs de l’application. Les responsabilités sont alors différentes. Nous ne fournissons pas les dépendances de l’application (PHP). Nous voyons ces containers comme une boîte noire : nous ne savons pas forcément quelles versions tournent à l’intérieur.

Pour ces infrastructures, nous avons contacté les développeurs pour s’assurer qu’ils aient bien connaissance des failles et leur avons vivement conseillé de reconstruire les containers dès la publication des correctifs

Que retenir de cette journée ?

Du point de vue de l’équipe, cela nous a permis de confirmer que nous étions capables d’opérer à grande échelle sur notre parc de serveurs. Nous l’avions déjà fait plusieurs fois cette année pour des applications de correctifs jugés critiques sur le noyau linux.

Cela nous conforte également dans les choix réalisés pour nos clients : l’utilisation de distributions stables avec des supports de sécurité étendus qui permettent de prévoir et planifier les montées de version.

D’un point de vue plus général, nous constatons une recrudescence de publications de failles. L’arrivée de l’IA a dopé les recherches de vulnérabilités. Du code qui n’avait pas été relu depuis des années est maintenant passé sous leur crible.

Ondřej Surý a sauvé la mise de quelques-uns sur ces CVE mais ce ne sera pas forcément le cas sur les prochaines, que ce soit sur PHP ou sur d’autres composants.

Il est par ailleurs utile de rappeler que les serveurs non maintenus ayant été patchés sur cette faille précise ne le sont pas forcément pour les précédentes, moins médiatisées et moins critiques, et ne le sont pas non plus sur tous les autres composants (il n’y a pas que PHP qui tourne sur un serveur web).

Il est plus que jamais nécessaire et critique de ne pas retarder les migrations vers des systèmes et des composants maintenus.