Failles PHP et FrankenPHP : comment nous avons corrigé nos sites en GitOps

CVE-2026-109618 et CVE-2026-109619 : patcher PHP et FrankenPHP sur tous vos sites Laravel avec Kubernetes et Kyverno

Le 21 octobre 2026, le projet PHP a publié un correctif pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619. Toutes deux peuvent permettre une exécution de code à distance sans authentification (CVSS v4.0 : 9,2).

Point clé pour les équipes Laravel : la faille est dans PHP, pas dans Laravel. Une application parfaitement à jour reste vulnérable si le runtime en dessous ne l'est pas. Il faut donc mettre à jour PHP sur chaque site, efficacement et rapidement.

Les avis de sécurité PHP

• CVE-2026-109618 : la gestion d'un manque de mémoire peut interrompre PHP alors que des données internes de la requête sont à moitié initialisées, que le nettoyage traite ensuite comme valides.

• CVE-2026-109619 : des données internes d'une requête survivent à la libération de leur mémoire, et une requête suivante traitée par le même worker peut les réutiliser.

• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.

• Exposition : tous les modes de service web (PHP-FPM, mod_php, FrankenPHP, LiteSpeed...).

• PHP 8.1 et antérieurs : plus de mises à jour officielles. Des rétroportages minimaux existent pour les branches 7.4, 8.0 et 8.1, et certaines distributions proposent leurs correctifs.

• Nuance : la publication avait été annoncée la veille, ce n'est donc pas un zero-day au sens strict, mais la fenêtre avant exploitation reste courte.

Le projet est formel : les mesures d'atténuation réduisent l'exposition mais ne remplacent pas la mise à jour.

La méthode en trois étapes

Pour des sites hébergés sur Kubernetes, la démarche suit le cycle classique de la réponse à incident : confinement pour réduire la surface d'attaque, éradication de la vulnérabilité à la source, puis remédiation vérifiée avant le retour à la normale.

1. Confinement : la page de maintenance

Tant qu'un site tourne sur un PHP vulnérable, le plus prudent est de le mettre à l'abri. Les visiteurs sont redirigés vers une simple page de maintenance indiquant que le site revient bientôt. Elle s'affiche en HTTPS, avec le même certificat que le site, donc aucun avertissement de sécurité ne les inquiète.

Cette bascule se fait au niveau de l'Ingress, la porte d'entrée du cluster, et se défait en un instant. Pendant ce temps, plus aucune requête n'atteint le moteur vulnérable. Les moteurs de recherche comprennent aussi que l'arrêt est temporaire.

2. Éradication : une image neuve, des pods remplacés

Avec Kubernetes, chaque site tourne dans un « conteneur » construit à partir d'une image, un peu comme un moule. Plutôt que de bricoler les serveurs un par un, on reconstruit l'image avec une version corrigée de PHP et de FrankenPHP, puis on supprime complètement les anciens pods (les conteneurs en cours d'exécution) pour en démarrer de nouveaux à partir de cette image.

Ce remplacement total est un choix volontaire : FrankenPHP garde l'application en mémoire d'une requête à l'autre, ce qui est justement le terrain de la seconde faille. Il faut donc s'assurer qu'aucun ancien processus ne survive. Et comme le site est déjà derrière la page de maintenance, la courte interruption ne gêne personne.

L'image corrective de FrankenPHP a été publiée 21 octobre vers 20h45, le soir même de la publication des correctifs PHP. Il n'y avait donc pas à attendre : il suffisait de reconstruire nos images sur cette nouvelle base. Avant de rouvrir un site, on contrôle malgré tout la version de PHP embarquée dans l'image, car c'est cette preuve, et non l'hypothèse que « le tag est le bon », qui permet de lever le confinement.

Si le nouveau site ne démarre pas correctement, Kubernetes permet de revenir en arrière en une commande.

3. Remédiation vérifiée : Kyverno

Corriger ne suffit pas : il faut aussi empêcher toute régression et prouver la conformité, afin qu'une image vulnérable ne soit pas redéployée par erreur ou par précipitation. C'est le rôle de Kyverno, qui fait office de point de contrôle à l'entrée du cluster et applique vos politiques de sécurité automatiquement :

• il recense les actifs encore vulnérables, ce qui donne votre plan de remédiation ;

• il bloque toute image non conforme une fois la phase d'audit terminée ;

• il peut imposer des mesures de durcissement communes, comme une limite de mémoire par conteneur ;

• il peut n'accepter que les images signées par votre chaîne de build, pour garantir leur provenance.

Le mode de déploiement : GitOps

Toutes ces opérations ont été menées en GitOps : l'état souhaité du cluster (la page de maintenance, la version de l'image, les politiques Kyverno) est décrit dans un dépôt Git, et un outil de synchronisation (comme Argo CD ou Flux) l'applique automatiquement et le maintient conforme. Concrètement, personne ne modifie le cluster à la main : on modifie Git.

Pour la gestion d'une vulnérabilité critique, les bénéfices sont nets :

• Traçabilité et audit : chaque changement est un commit daté et signé, avec son auteur. À la question « qui a corrigé quoi, et à quelle heure ? », la réponse est dans l'historique, ce qui sert aussi de preuve de remédiation.

• Contrôle des changements : la bascule en maintenance et le remplacement des images peuvent passer par une revue avant d'être appliqués, ce qui limite les erreurs commises dans l'urgence.

• Retour arrière fiable : annuler un changement revient à annuler un commit, et le cluster revient à l'état précédent connu.

• Protection contre la dérive : si quelqu'un modifie le cluster en dehors de Git, l'outil de synchronisation le détecte et le corrige. Un site ne peut donc pas repasser discrètement sur une configuration vulnérable.

• Moins d'accès sensibles : on n'a plus besoin de donner des droits d'administration sur le cluster à chaque intervenant, seul l'outil de synchronisation les détient.

Ce qu'il faut garder en tête

• Ces outils ne remplacent pas la veille : il faut suivre les annonces de sécurité de PHP

• Les versions de PHP sans support doivent être migrées, par exemple PHP 8.2 arrive en fin de vie le 31 décembre 2026.

• Côté Laravel, vérifiez que les sessions, le cache et les files d'attente ne dépendent pas des anciens conteneurs, pour ne rien perdre lors du remplacement.

• Une règle de blocage trop stricte peut gêner des déploiements légitimes : toujours tester d'abord en observation.

• Ne regardez pas seulement PHP : toute la chaîne de dépendances compte. Un site est un empilement : système de base de l'image, PHP et ses extensions, serveur applicatif comme FrankenPHP, paquets Composer de Laravel, et même les bibliothèques JavaScript. Une faille peut surgir à n'importe quel étage, et c'est souvent la couche que l'on ne surveille pas qui est touchée. Tenez un inventaire à jour de ce qui compose chaque image (une nomenclature logicielle, ou SBOM), analysez-le en continu avec un scanner de vulnérabilités plutôt qu'une fois par an, mettez à jour régulièrement par petites étapes pour éviter les gros retards, et fixez les versions pour savoir exactement ce qui tourne. Plus vos mises à jour sont habituelles et automatisées, moins un correctif urgent est une épreuve !

Conclusion

La page de maintenance coupe l'exposition, Kubernetes remplace le moteur proprement, Kyverno verrouille le résultat. La question « quels sites sont encore vulnérables ? » trouve alors une réponse en quelques minutes, au lieu d'une enquête serveur par serveur de plusieurs heures voir plusieurs jours.