Les CVE-2026-109618 et 2026-109619 ont agité les communautés et de nombreux médias annonçaient l'arrêt d'Internet, le monde au bord du chaos, etc. La fondation PHP a retracé l'historique de ces failles. 

Un audit détecte un problème dès 2024 !

PHP fait l'objet d'un audit par outil de sécurité externe. Cela a pu se faire grâce à un financement spécial via OSTIF. L'audit est réalisé par Quarkslab. Des problèmes sont remontés. Dont un... "En corrigeant l'un des problèmes signalés par Quarkslab, un développeur du noyau PHP, sous contrat avec la Fondation PHP, a découvert les premiers signes du problème de mémoire (OOM) à l'origine de la CVE-2026-109618. En 2024, une exploitation potentielle de cette vulnérabilité a été envisagée, mais aucun vecteur concret n'a été trouvé et d'autres problèmes concrets, ayant un impact évident, ont éclipsé ces préoccupations."

Pour résoudre ce problème de out of memory, l'équipe de sécurité PHP développe plusieurs solutions mais chaque proposition introduit des inconvénient dont :

- casse de compatibilité

- risque d'attaque par déni de service

- nombreuses modifications d'extensions externes

Durant plusieurs mois, l'équipe de sécurité ne parvient pas à se mettre d'accord, le développement est arrêté, relancé ou refait. La fondation est obligée d'admettre une défaillance interne de l'organisation : "Nous ne le nions pas : ce retard était dû à une défaillance structurelle, imputable à la fois au processus décisionnel de l’équipe de sécurité et à son manque de ressources. Depuis, l’équipe de sécurité a entrepris de modifier ses processus, et ce travail se poursuit, afin que les décisions soient prises à la majorité et que les compromis soient encouragés."

Sauf que cette non-correction dure des mois. En mai 2026, la fondation crée une équipe de sécurité de l'écosystème PHP, en collaboration avec l'équipe de sécurité interne pour trier et donner les priorités... L'équipe est renforcée par plusieurs personnes.

Début 2026, la fondation rappelle un problème avec Mythos pour tester PHP et la plateforme. Le 30 juillet 2026, un nouvel audit est lancé par Calif. 

11 août : ""Ryan A., chercheur chez Calif, a signalé une exécution de code à distance inconditionnelle ayant la même cause que le problème de mémoire insuffisante (OOM) que nous avions découvert en 2024." Cela signifie que les failles out of memory de 2024 sont toujours là.

24 août et 18 septembre : OpenAI et Wiz identifient de nouvelles failles.

Cette succession de failles et des mêmes causes alerte PHP du problème profond et de l'urgence de trouver une solution pérenne. La fondation PHP a soutenu les équipes pour mobiliser les développeurs et fixer les failles. Dans le même temps , PHP signale que la sécurité par IA génère aussi beaucoup de retours et l'équipe de sécurité interne connaît une charge de travail supplémentaire : 15 CVE publiées depuis le 1er juillet et plus de 100 signalements traités dont la plupart, ou tous, se sont révélés non exploitables ou des faux positifs. 

20 octobre : la catastrophe se produit !

Les vulnérabilités sont divulguées, 2 jours avant la publication officielle des CVE. Dès 15h UTC, les CVE commencent à circuler. Les détails techniques ne sont pas donnés. Face à l'urgence, le projet PHP avance l'annonce des CVE au 21 octobre. "Avancer la publication d'un jour constituait le meilleur compromis entre la rapidité d'action, le temps nécessaire à la préparation et la simplicité de la procédure de mise à jour pour tous suite à la divulgation des vulnérabilités."

Calif publie par erreur une vidéo montrant un PoC d'exploitation des CVE ! Elle est supprimée immédiatement mais c'est déjà trop tard. Et la vidéo et les informations circulent rapidement le 21 octobre. Le projet PHP précise avoir fourni à plusieurs fournisseurs technologiques des méthodes pour réduire les risques. Ont-elles fuité ?

21 octobre 7h41 UTC : PHP explique que Chainguard n'a pas respecté l'embargo sur les CVE et publie des éléments inlcuant le correctif que le projet PHP a développé. "N'importe quel attaquant pouvait désormais étudier le correctif sous forme binaire, alors que tous les autres utilisateurs de PHP attendaient encore sa publication. Cela a anéanti des semaines de travail menées par de nombreuses parties en vue d'une divulgation coordonnée."

La suite vous la connaissez...

Notre avis : on pouvait se douter que les deux CVE n'étaient pas apparues par magie, surtout quand elles touchent la mémoire. La fondation PHP a le mérite de publier sa vérité sur cette affaire. Nous pouvons faire 4 constats :

1 / les premières failles menant aux CVE sont découvertes dès 2024

2 / les équipes de sécurité PHP n'arrivent pas à se coordonner sur une solution unique et durant des mois, rien ne bouge réellement et aucune décision ne semble avoir été prise

3 / il faut attendre l'été 2026 pour que PHP y voit un problème majeur de ces failles

4 / la fondation PHP reconnaît ses erreurs, la défaillance d'organisation et l'absence de priorité pour les failles de 2024. Mais, elle cherche aussi à rejeter, au moins en partie, la panique des CVE critiques, sur d'autres personnes et éditeurs du marché qui n'auraient pas respecté les règles. 

On peut effectivement pointer l'erreur de Calif ou l'attitude de certains fournisseurs mais cela ne dédouane pas PHP sur les conséquences de ces CVE depuis les premières découvertes en 2024.

Texte complet : https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

Catégorie actualité: SécuritéPHPImage actualité AMP: