Mise à jour de sécurité de PHP et comment nous renforçons la sécurité de PHP, par la Fondation PHP

Plus tôt dans la journée, l'équipe du projet PHP a publié les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux failles critiques qui, dans certaines conditions, permettent à un attaquant non authentifié d'exécuter du code sur des serveurs exécutant PHP. Si vous utilisez PHP, il est impératif que vous effectuiez la mise à jour dès maintenant. L'annonce publiée sur php.net contient et fait référence à des détails techniques concernant ces vulnérabilités, les vecteurs d'attaque, ainsi que des instructions sur la manière de procéder à la mise à jour sur les différents systèmes.

Cet article ne traite pas de la procédure de mise à jour. Il explique comment ces vulnérabilités ont été découvertes et corrigées, ce qui a changé dans la gestion de la sécurité de PHP au cours des deux dernières années, et ce que nous attendons des organisations qui dépendent de PHP pour que le travail de sécurité autour de PHP se poursuive.

Deux vulnérabilités critiques liées à l’exécution de code à distance

- CVE-2026-109618 / GHSA-w8hw-w9fx-j79w : RCE via une corruption OOM (manque de mémoire) : si une requête atteignait la limite memory_limit de PHP exactement au mauvais moment, PHP pouvait laisser derrière lui des données internes partiellement initialisées et les traiter ultérieurement comme valides, corrompant ainsi la mémoire. Sur Apache avec mod_php, une requête non authentifiée peut déclencher ce problème avant même l’exécution du code de l’application, et une exécution de code à distance complète a été démontrée avec les paramètres par défaut. L’exécution de code à distance a également été confirmée sur PHP-FPM via des chemins de code au niveau de l’application.

- CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp : RCE via un état global obsolète : Une erreur fatale survenue au mauvais moment pouvait laisser l’état interne pointer vers de la mémoire appartenant à une requête précédente. Une requête ultérieure traitée par le même worker pouvait alors utiliser cette mémoire libérée. Une utilisation après libération (use-after-free) et un plantage du worker ont été confirmés, et l’auteur du rapport a démontré l’exécution de code à distance sur une application réelle fonctionnant sous Apache avec mod_php.

Ces deux vulnérabilités se situent dans des parties de PHP que presque toutes les requêtes utilisent : la gestion de la mémoire et la gestion des erreurs. C’est précisément leur place centrale au sein de PHP qui a rendu ces deux vulnérabilités graves, mais aussi très difficiles à corriger sans compromettre la compatibilité, nuire aux performances ou imposer des changements au vaste écosystème d’extensions tierces.

Un premier audit externe et une attention accrue portée à la sécurité

En 2024, PHP a fait l’objet de son premier audit de sécurité externe depuis des années. La Fondation PHP a obtenu un financement de la Sovereign Tech Agency pour organiser cet audit par l’intermédiaire de l’OSTIF, et celui-ci a été réalisé par Quarkslab. Alors qu’il corrigeait l’un des problèmes signalés par Quarkslab, un développeur du noyau PHP engagé par la Fondation PHP a découvert les premiers signes du problème OOM à l’origine de la faille CVE-2026-109618. En 2024, un exploit potentiel pour ce problème OOM avait été théorisé, mais aucun vecteur concret n’avait été identifié et d’autres problèmes concrets ayant un impact évident avaient éclipsé ces préoccupations.

Pour corriger le problème OOM, l’équipe de sécurité de PHP a développé plusieurs approches concurrentes, mais chacune présentait ses propres compromis : rupture de la rétrocompatibilité, nouveau risque de déni de service, ou nécessité de modifier de nombreuses extensions tierces, ce qui semblait impossible à coordonner. L’équipe de sécurité de PHP, fonctionnant par consensus, a eu du mal à choisir entre ces options et craignait les répercussions d’une mise en production du mauvais choix. Combiné à l’absence de vecteur connu permettant l’exécution de code à distance et à la petite taille de l’équipe de développeurs principaux possédant les connaissances approfondies nécessaires du moteur et déjà accablée de nombreuses responsabilités, ce processus décisionnel a entraîné des blocages et des redémarrages répétés du travail sur le correctif pendant des mois. Nous ne ferons pas semblant de croire le contraire : ce retard était un échec structurel, causé à la fois par le processus décisionnel de l’équipe de sécurité et par son manque de ressources. Depuis, l’équipe de sécurité a commencé à modifier ses processus, et ce travail se poursuit, afin que les décisions puissent être prises à la majorité et que les compromis soient encouragés.

Mettre en place une organisation de sécurité professionnelle et durable

Au cours des derniers mois, l’organisation du travail de sécurité autour de PHP a considérablement évolué. En mai 2026, la Fondation PHP a créé l’équipe de sécurité de l’écosystème (Ecosystem Security Team), qui travaille aux côtés de l’équipe de sécurité PHP sur le triage, la coordination et le renforcement de la sécurité. Le travail de Volker Dusch en tant qu’ingénieur en sécurité IA en résidence à la Fondation PHP a considérablement amélioré la communication et la collaboration entre l’équipe de sécurité PHP et la Fondation. Alexandre Daubois a rejoint la Fondation PHP en juillet pour aider l’équipe de sécurité PHP à trier, traiter et corriger les rapports de sécurité, et Daniel Scherzer l’a rejointe en septembre pour prendre en charge les travaux de renforcement de la sécurité.

Plus tôt cette année, nous avons collaboré avec Alpha-Omega pour analyser PHP à l’aide de Claude Mythos d’Anthropic. Mais depuis cette analyse Mythos, nous avons ajouté d’autres outils, notamment Daybreak Red d’OpenAI pour valider les rapports et les exploits, ainsi que des versions « sanitizer » et des environnements de reproduction adaptés à notre intégration continue (CI) sur toutes les plateformes prises en charge par PHP.

La Fondation PHP a intégré le projet PHP au programme « Patch the Planet », dans le cadre duquel la société de sécurité Calif a lancé un audit de PHP le 30 juillet 2026. Le 11 août, le chercheur Ryan A, de Calif, a signalé une faille permettant l’exécution de code à distance sans condition, dont la cause première était identique à celle du problème OOM que nous avions découvert en 2024. OpenAI a signalé de manière indépendante cette même cause première, suivie par d’autres vecteurs d’attaque identifiés par OpenAI le 18 septembre et par Wiz le 24 août. Plus récemment, Trail of Bits a également procédé à un audit de PHP. Les rapports de Calif, d’OpenAI et de Wiz ont mis en évidence toute l’ampleur du problème de mémoire insuffisante (OOM), et à partir du 11 août, sa résolution est devenue la priorité absolue pour toute l’équipe de la Fondation PHP chargée de la sécurité. Sans le financement de la Fondation, il aurait été impossible de mobiliser plusieurs personnes à plein temps sur ce problème, travaillant parfois le week-end et 24 heures sur 24 pour coordonner et communiquer avec les autres parties concernées.

Le développement de la recherche assistée par l’IA signifie également que l’équipe de sécurité PHP reçoit beaucoup plus de rapports qu’auparavant. Comme l’a décrit Alexandre Daubois la semaine dernière dans « Comment l’équipe de sécurité PHP traite vos rapports », l’équipe a publié 15 CVE depuis le 1er juillet et a examiné plus de 100 rapports qui se sont avérés invalides, en double ou non reproductibles. L’IA aide l’équipe à valider les rapports et à regrouper ceux qui partagent la même cause première, mais c’est une personne qui prend chaque décision et travaille sur chaque correctif.

Fuite et divulgation perturbée

La divulgation coordonnée de ces vulnérabilités s’est bien déroulée jusqu’à deux jours avant la date de publication prévue.

Le mardi 20 octobre, vers 15 h 00 UTC, les deux identifiants CVE ont commencé à circuler sur des forums en ligne et les réseaux sociaux. Ils étaient accompagnés d’une heure de publication erronée et d’un score CVSS incorrect de 10,0 (le score réel est de 9,2). Aucun détail technique n’a fuité. En réponse, le projet PHP a avancé la date de son annonce préalable et l’a publiée à 19 h 30 UTC. Il a également avancé la date de publication du 22 octobre à 14 h 00 UTC au 21 octobre à 14 h 00 UTC. Les distributeurs étaient encore en train d’intégrer le correctif ; une publication immédiate aurait donc privé de nombreux utilisateurs d’un moyen simple de se mettre à jour. Avancer la publication d’un jour constituait le meilleur compromis entre agir rapidement, laisser aux utilisateurs le temps de se préparer et s’assurer que chacun dispose d’un processus de mise à jour simple une fois les vulnérabilités divulguées.

À la suite de la fuite et de l’annonce préalable vers 20 h 00 UTC, Calif, l’une des sociétés de sécurité ayant signalé les problèmes, a publié par erreur une vidéo. Celle-ci montrait leur preuve de concept fonctionnant contre plusieurs cibles et révélait quelques détails supplémentaires, bien que limités, concernant les vulnérabilités. Des copies de la vidéo supprimée ont commencé à circuler sur les réseaux sociaux peu après. Cette vidéo a contribué à accélérer le développement de divers PoC (preuves de concept d’exploitation), ce qui a ensuite entraîné une augmentation de leur diffusion le 21 octobre.

Les conseils de mitigation que nous avions commencé à fournir à quelques fournisseurs d’infrastructures critiques vers 23 h 00 UTC le 20 octobre ont peut-être également fait l’objet d’une fuite. L’équipe de sécurité PHP a étroitement surveillé et inspecté les PoC apparaissant après la fuite, mais n’a identifié aucun exploit fonctionnel au moment de la publication ou de la divulgation publique.

Le 21 octobre à 07 h 41 UTC, soit plus de six heures avant la publication coordonnée, Chainguard a unilatéralement rompu l’embargo et publié des images précompilées contenant le correctif. À l’instar d’autres distributeurs, Chainguard avait reçu le correctif à l’avance afin que ses utilisateurs puissent effectuer la mise à jour dès la divulgation des vulnérabilités. Tout attaquant pouvait désormais étudier le correctif sous forme binaire alors que tous les autres utilisateurs de PHP attendaient encore la publication. Cela a réduit à néant des semaines de travail menées par de nombreuses parties en vue d’une divulgation coordonnée.

Une perspective prudemment optimiste

La publication d’aujourd’hui témoigne des progrès que nous réalisons dans la gestion de la sécurité de PHP. Une fois que l’impact complet du problème OOM a été compris en août, l’équipe de sécurité, la fondation et les responsables de la publication ont fourni un correctif pour ce problème profondément enraciné sur toutes les branches prises en charge, et les distributions ainsi que les fournisseurs LTS ont reçu le correctif à l’avance afin que leurs utilisateurs puissent se mettre à jour rapidement.

Nous sommes convaincus qu’une vulnérabilité grave dont le correctif se heurte à des compromis difficiles serait désormais portée à l’attention de la direction de la Fondation PHP bien plus rapidement, car nous modifions nos processus afin que celle-ci puisse contribuer à orienter la situation vers une résolution en temps opportun. Nous accordons désormais la priorité aux mesures visant à garantir que les vulnérabilités nécessitant des correctifs d’une complexité similaire soient résolues plus rapidement lorsqu’elles seront signalées à l’avenir. La Fondation PHP et l’équipe de sécurité PHP ont beaucoup appris au cours des dernières semaines et s’efforceront de transformer leurs expériences en processus durables et reproductibles.

Ce que nous attendons de vous

PHP est utilisé par une grande partie du Web, notamment les services publics, les boutiques en ligne, les banques, les sites d’information et une grande partie des logiciels sur lesquels les entreprises s’appuient au quotidien. Pourtant, le travail de sécurité sur PHP lui-même dépend encore d’un petit groupe de développeurs financés par la Fondation et d’un peu d’aide bénévole.

Les outils détectent désormais les failles plus rapidement que jamais, tant pour les défenseurs que pour les attaquants, et le nombre de signalements ne cessera d’augmenter. Ce que les outils ne peuvent pas faire, c’est déterminer la correction appropriée pour un choix de conception de longue date au sein du moteur, évaluer les compromis en matière de compatibilité et examiner le correctif. Prendre ces décisions nécessite des ingénieurs expérimentés qui connaissent l’intégralité du code source de PHP, et ceux-ci sont aujourd’hui trop peu nombreux.

Un élément central de la mission de la Fondation PHP consiste à augmenter le nombre d’ingénieurs possédant une connaissance approfondie de la base de code PHP et à fournir à l’équipe de sécurité les ressources dont elle a besoin. Nous ne pouvons atteindre cet objectif qu’avec le soutien financier de ceux qui dépendent de PHP :

- Les entreprises qui développent des produits et des services basés sur PHP : veuillez parrainer la Fondation PHP à hauteur de votre dépendance à son égard.
- Les hébergeurs, les plateformes cloud et les distributions qui mettent PHP à la disposition de millions d’utilisateurs.
- Les gouvernements et les institutions publiques dont les services fonctionnent sous PHP. Le financement de l’audit 2024 par l’Agence allemande Sovereign Tech montre ce que l’investissement public peut accomplir, et nous avons besoin de davantage de moyens de ce type, de manière durable.

Parrainer la Fondation PHP est le moyen le plus direct de garantir que les problèmes structurels, tels que la vulnérabilité OOM, soient traités de manière durable, avant qu’ils ne se transforment en situations d’urgence. Devenez sponsor sur thephp.foundation/sponsor, et si votre organisation souhaite discuter d’un engagement plus important, n’hésitez pas à nous contacter.

Merci

Merci à l’équipe de sécurité PHP, aux bénévoles et aux prestataires de la Fondation PHP, aux responsables de publication, ainsi qu’aux mainteneurs de paquets des distributions et des fournisseurs LTS qui ont rendu ces versions possibles. Merci à Calif, en particulier à Ryan A, Wiz, OpenAI Codex Security, notamment Amy Burnett, OSTIF et Quarkslab pour leurs recherches et leur divulgation responsable ; à Alpha-Omega, OpenAI et Anthropic pour avoir donné à l’équipe accès à leurs outils et financé une partie des travaux de sécurité ; à la Sovereign Tech Agency pour avoir financé l’audit de 2024 ; et à tous nos sponsors, dont le soutien a rendu ce travail possible.

Source : Fondation PHP

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Des centaines de sites Web mis hors ligne alors que deux failles de sécurité majeures dans PHP sèment la panique dans le monde : « mettez-les hors ligne si vous n'avez pas encore installé le correctif »

PHP 8.5 est désormais disponible avec une fonctionnalité très attendue : l'opérateur pipe, une petite fonctionnalité au potentiel énorme mais qui a pris des années à voir le jour

La Fondation PHP recherche activement un nouveau directeur exécutif pour diriger sa mission de promotion du langage PHP, dans un contexte marqué par des lancements récents et une augmentation des parrainages

Vous avez lu gratuitement 136 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.