On essaie de remplacer PHP depuis quinze ans. Pourquoi son moteur est-il toujours là ?

En octobre 2026, deux failles du moteur PHP entraînent des mises hors ligne dans plusieurs pays. L’occasion de revenir sur les tentatives de remplacement de PHP, de HHVM à Rust, et sur ce qui les rend si difficiles : la compatibilité avec les applications existantes.

27 octobre 2026. Chiffres et état des projets arrêtés à cette date.

Octobre 2026 : deux CVE et des correctifs précipités

Le 20 octobre 2026, les identifiants de deux vulnérabilités PHP circulent sur des forums avant leur divulgation officielle. Un score de 10/10 se propage, à tort : les deux failles sont notées 9,2 en CVSS v4.0. Toutes deux concernent la gestion mémoire et peuvent permettre une exécution de code à distance sans authentification, sous certaines conditions. PHP avance sa pré-annonce à 19 h 30 UTC et décide de publier les correctifs le 21 octobre au lieu du 22. Vers 20 h, Calif, société impliquée dans la découverte, met accidentellement en ligne une vidéo de démonstration. Elle est retirée rapidement, mais déjà diffusée ailleurs. 1

Le 21 octobre, à 7 h 41 UTC, Chainguard distribue des images contenant le correctif, plus de six heures avant l’heure convenue. La PHP Foundation dénonce une rupture d’embargo. Les versions PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 sont publiées à 14 h UTC. Le CERT-FR recommande d’isoler les systèmes exposés en attendant leur mise à jour. Plusieurs sites administratifs français affichent des pages de maintenance préventive. 1, 2, 3

Les interruptions dépassent les frontières françaises. Reuters cite l’ITZBund allemand, le ministère belge des Affaires étrangères, le Port de Rotterdam et des hôpitaux néerlandais. Wikimedia, Internet Archive, la BBC, plusieurs services publics ou entreprises au Japon, ainsi qu’Orange en France, prennent également des mesures. Ces interruptions, parfois préventives, ne démontrent pas que les organisations concernées ont été compromises. 4

Les alertes continuent après les correctifs. Entre le 21 et le 26 octobre, watchTowr observe des tentatives d’exploitation ; le CERT-FR en confirme sur des déploiements précis. Une troisième vulnérabilité, CVE-2026-115560, liée à session.upload_progress, est annoncée le 23 octobre. Trois jours plus tard, la CISA ajoute CVE-2026-109618 à son catalogue KEV des vulnérabilités exploitées.

Chronologie : PHP Foundation, CERT-FR, watchTowr. Les tentatives observées ne signifient pas que tous les déploiements PHP sont exploitables. 1, 2, 5

Sous le nom « PHP2Shell », on trouve deux défauts distincts dans Zend, le moteur de PHP :

• CVE-2026-109618 : lorsqu’une allocation atteint memory_limit, un longjmp() interrompt brutalement une initialisation. Le nettoyage peut ensuite retrouver des structures partiellement initialisées et corrompre la mémoire. Sur Apache avec mod_php, une exploitation complète a été démontrée avant même l’exécution du code applicatif. 6
• CVE-2026-109619 : une erreur fatale, un dépassement de temps ou un diagnostic tardif peut empêcher la remise à zéro d’un état global conservé par un worker. Une requête ultérieure, sur ce même worker, réutilise alors un pointeur vers de la mémoire libérée : c’est un use-after-free. Un chemin d’exploitation impliquant le cycle de vie de session.upload_progress a notamment été validé sur FPM. 7

CVE-2026-115560 suppose une configuration plus particulière : le sérialiseur de sessions doit être réglé sur php_binary ou php_serialize, puis remplacé par php dans le code avant session_start(), avec le suivi des téléversements actif. Ce suivi est activé par défaut, mais cette seule condition ne suffit pas pour exploiter la faille. PHP recommande temporairement session.upload_progress.enabled=0 pour écarter ce vecteur, en attendant le correctif prévu dans le cycle normal. 8, 9

Face à ces bugs mémoire, la réécriture de PHP en Rust mérite qu’on s’y intéresse. Rust empêche par conception une grande partie des erreurs d’accès mémoire permises en C. La difficulté est de conserver tous les comportements que les applications attendent de PHP.

Rust : supprimer des bugs mémoire sans inventer un autre PHP

En juin 2026, Francesco Tinti crée php-rust. Il reconstruit le parseur, la compilation en bytecode, la machine virtuelle, le ramasse-miettes et les fonctions internes. L’objectif est de reproduire le comportement observable de PHP, sans reprendre l’architecture de Zend. 10

Le Rust sûr évite les accès hors limites, les doubles libérations et les use-after-free. La garantie s’arrête toutefois aux frontières unsafe et FFI, notamment lorsque le programme appelle des bibliothèques C. php-rust s’appuie déjà sur des bibliothèques natives pour certaines fonctions multimédias et de compression. Il lui faut donc assurer à la fois la sûreté de sa propre mémoire et la compatibilité des applications.

Au 27 octobre, le dépôt compte 283 étoiles et 11 forks. php-rust reste un petit projet face à Zend, même si les résultats annoncés pour quelques mois de développement sont substantiels. Ils proviennent des tests de l’auteur : ils ne constituent ni une validation indépendante ni une garantie d’aptitude à la production. 10, 11

La couverture varie fortement selon ce qu’on mesure. 1 017 des 2 143 fonctions internes sont disponibles (47 %), car plusieurs extensions entières n’ont pas encore été portées. Pour le cœur du langage, les fonctions standard et les dates, la couverture grimpe à 539 sur 654 (82 %).

Côté validation, 2 655 tests Zend passent sur 4 067 exécutables (65,3 %). Le corpus contient au total 5 305 tests, dont 1 238 sont ignorés, notamment faute d’extensions. Quant à WordPress, l’auteur revendique une quasi-parité avec la suite de tests du cœur, sur les versions et scénarios effectivement évalués.

Mesures du 16 septembre 2026, établies et publiées par le projet contre PHP 8.5.7. 11

Sur les performances, php-rust accuse encore du retard. Le langage d’implémentation ne suffit pas à battre Zend, dont les valeurs, le copy-on-write, OPcache et le JIT ont bénéficié d’années d’optimisation. Un interpréteur neuf doit retrouver des optimisations comparables.

Dans les micro-benchmarks publiés, php-rust consomme 2,1 fois plus de temps CPU en arithmétique, 2,3 fois plus pour les propriétés d’objet et 2,9 fois plus pour les tableaux. Le ratio atteint ×3,5 sur les appels de fonctions et ×4,3 sur les chaînes de caractères.

Sur les suites applicatives, l’auteur mesure environ ×1,75 pour WordPress et ×7 pour Doctrine ORM.

Mesures internes d’octobre 2026, pas benchmarks indépendants. « ×2 » signifie deux fois plus de temps CPU, et non deux fois moins de requêtes HTTP par seconde. 12

Il reste la question des extensions natives. Une extension redis.so, imagick.so, Xdebug ou un agent de supervision compilé pour l’ABI Zend ne peut pas être chargé tel quel par une autre machine virtuelle. Le nouveau moteur doit recréer son comportement ou fournir une interface native compatible, au risque de réintroduire une partie des problèmes de mémoire.

La compatibilité du langage réserve aussi des pièges. Le 25 octobre, un contributeur signale que filter_var('not-an-email', FILTER_VALIDATE_EMAIL) renvoie sous php-rust la chaîne d’origine au lieu de false. FILTER_VALIDATE_DOMAIN est également concerné. Une PR de correction est alors ouverte. Cette divergence ne provoque pas de corruption mémoire ; elle peut en revanche laisser passer une donnée que l’application croit avoir validée. 13, 14

D’autres interpréteurs Rust, comme le php-rs expérimental de wudi, explorent la même voie sans prétendre constituer aujourd’hui une alternative générale à Zend. 15

Le dépôt documente aussi une méthode de développement fortement assistée par IA : plans de sessions numérotées, consignes destinées aux agents, revues contradictoires et commits mentionnant Claude. Les protocoles de test et de mesure sont détaillés. Ce mode de développement ne suffit ni à invalider les résultats ni à garantir leur fiabilité. Reste une question de maintenance : qui adaptera ce moteur aux évolutions futures de PHP ? 10, 12

HHVM : quand Facebook a choisi Hack

Au début des années 2010, Facebook cherche à réduire le coût d’exécution de PHP. Après HipHop, un traducteur de PHP vers C++, l’entreprise développe HHVM, une machine virtuelle dotée d’un compilateur JIT. Face à PHP 5, elle obtient des gains de performances considérables.

Fin 2015, PHP 7 change le rapport de force en accélérant fortement Zend. En mai 2017, Fabien Potencier annonce la fin du support HHVM dans Symfony 4 : les différences de comportement demandent trop d’efforts, l’avantage de vitesse s’est réduit et moins de 4 % des répondants à sa consultation souhaitent conserver le support. 16, 17

En 2014, Facebook présente Hack, un langage dérivé de PHP avec un système de types plus ambitieux. En septembre 2018, l’équipe HHVM annonce qu’elle abandonne la compatibilité PHP. La version 4.0, sortie en février 2019, confirme ce choix : l’équipe peut faire évoluer Hack sans devoir reproduire chaque changement de PHP. 18, 19

HHVM continue de servir chez Meta. En mai 2025, l’entreprise publiait encore des optimisations destinées aux traitements longs liés à l’IA générative. En revanche, les releases open source officielles avaient été arrêtées en 2023. Meta invoquait le coût du maintien d’anciennes versions face à l’automatisation et à la cadence de ses releases internes, ainsi que l’abandon de GCC au profit de Clang ; elle n’expliquait pas cette décision par une absence d’utilisateurs externes. 20, 21

L’histoire de HHVM n’est donc pas celle d’un simple échec : c’est celle d’une technologie qui a réussi en cessant de vouloir être PHP.

D’autres façons de réinventer PHP

Les autres projets montrent qu’on peut modifier PHP de plusieurs façons : compiler le code pour une autre plateforme, réécrire le runtime ou réutiliser Zend dans un nouvel environnement.

Figure 1 — Réécrire le moteur, compiler vers une autre plateforme, ou conserver Zend. WordPress Playground appartient clairement à cette dernière catégorie.

Quelques exemples :

• KPHP compile un sous-ensemble de PHP en C++, puis en binaire natif, au prix de restrictions sur certaines fonctionnalités dynamiques.
• PeachPie compile PHP pour .NET et privilégie l’interopérabilité avec C#, avec une bibliothèque d’exécution à adapter.
• HippyVM et JPHP explorent d’autres machines virtuelles et des usages plus spécifiques.
• WordPress Playground compile le PHP officiel en WebAssembly : le moteur reste Zend, avec les contraintes du navigateur.
• ext-php-rs permet d’écrire des extensions Zend en Rust, sans faire disparaître la frontière FFI/unsafe.

Le compromis apparaît surtout avec KPHP, qui accepte de restreindre le langage pour faciliter la compilation native. WordPress Playground fait l’inverse : il conserve Zend et l’exécute en WebAssembly. ext-php-rs réduit la part de C dans les extensions, sans supprimer leur interface native. PeachPie, lui, cherche surtout l’interopérabilité avec C#. 22, 23, 24, 25

FrankenPHP : moderniser PHP sans toucher à Zend

FrankenPHP est probablement l’approche la plus directement utilisable aujourd’hui parmi ces alternatives. Le serveur s’appuie sur Caddy, écrit en Go, mais exécute le PHP officiel via son API native. Les requêtes PHP tournent dans des threads avec Zend Thread Safety (ZTS). Le moteur conserve donc son comportement et ses extensions, sous réserve de leur compatibilité ZTS. 26

Figure 2 — L’unité de défaillance n’est pas la même. Un enfant FPM traite plusieurs requêtes successives, pas un nouveau processus par requête ; FrankenPHP traite plusieurs requêtes dans les threads d’un même processus.

Avec mod_php, Zend vit dans les processus Apache : le serveur web et son interpréteur sont étroitement couplés. Avec Nginx + PHP-FPM, un processus maître supervise des enfants réutilisés au fil des requêtes ; si l’un meurt, les autres continuent. Avec FrankenPHP, plusieurs threads PHP partagent un processus unique. Cela simplifie l’intégration HTTP, mais change le rayon d’impact d’un plantage natif.

Les analyses de CVE-2026-109618 éclairent la différence entre ces architectures :

• Apache + mod_php : une RCE a été démontrée avant le code applicatif, avec la configuration par défaut. Le traitement et le nettoyage de la requête restent dans le worker Apache.
• PHP-FPM : le processus enfant quitte si l’initialisation échoue. L’advisory ne documente pas de chaîne complète pour cette CVE sur FPM, ce qui n’exclut ni les chemins applicatifs ni CVE-2026-109619.
• FrankenPHP : l’advisory juge ce modèle probablement exposé à la voie indépendante de l’application, par analogie avec mod_php. Une défaillance fatale du processus peut toucher toutes ses requêtes simultanées.

Nuance documentaire : l’advisory ne décrit aucune démonstration complète pour CVE-2026-109618 sur FPM, alors que la PHP Foundation indique qu’une RCE via un chemin applicatif y a été confirmée. Ces formulations publiques ne sont donc pas parfaitement alignées. Ni FPM ni FrankenPHP ne doivent être considérés comme immunisés. 1, 6, 7

FrankenPHP propose deux usages. Son mode classique réinitialise le contexte applicatif entre requêtes. Son mode worker conserve l’application initialisée : Composer, routeur et conteneur de dépendances n’ont plus à être reconstruits. Éviter cette initialisation peut accélérer le traitement des requêtes, à condition de maîtriser les états conservés entre deux appels. Pour le mode classique, une mesure indépendante de Tideways en septembre 2025 trouvait des performances proches de PHP-FPM, avec des écarts selon la charge et parfois un p99 moins bon. 27, 28

Ce risque de fuite d’état s’est déjà matérialisé. En février 2026, CVE-2026-24894 montrait qu’en mode worker, le contenu de $_SESSION pouvait être accessible à la requête suivante traitée par le même worker, avant son propre appel à session_start() ; le défaut a été corrigé en 1.11.2. Le 21 octobre, l’advisory GHSA-4gfw-9v29-gp9h documentait un autre état non réinitialisé : des informations de diagnostic libxml (et, selon les notes de version, error_get_last()) pouvaient exposer des fragments de documents ou des chemins du serveur à la requête suivante sur le même thread. La correction figure dans FrankenPHP 1.13.2, qui corrige aussi trois autres failles propres au serveur (répertoire temporaire prévisible, déni de service dans l’attente d’un thread, crash sur tableau cyclique). Ces fuites d’état ne sont pas les mêmes vulnérabilités que celles de Zend : elles proviennent du cycle de vie particulier des workers persistants. 29, 30, 31

Le correctif d’octobre change lui-même le comportement de PHP

Le correctif des deux CVE modifie aussi la gestion des erreurs mémoire. Le commit 31c0ea7d 32 abandonne le longjmp() immédiat sur manque de mémoire : PHP reporte désormais l’erreur fatale « souple » au prochain point d’exécution sûr. En cas de dépassement d’un seuil mémoire dur, configurable via memory_hard_limit_percent, il quitte immédiatement le processus, sans nettoyage classique. La limite dure vaut normalement 200 % de memory_limit, ou memory_limit + 1 Gio au-delà de 1 Gio. 6, 33

Dans FPM, cet arrêt touche un enfant du pool. Dans FrankenPHP, la documentation précise qu’il arrête le serveur et toutes les requêtes en cours jusqu’au redémarrage. L’issue php-src #24492, toujours ouverte lors de la consultation, signale déjà des cas où sprintf(), pack() ou bin2hex() déclenchent cet arrêt là où les versions précédentes produisaient une erreur mémoire récupérable. Il s’agit d’un signalement à investiguer, pas d’une régression généralisée démontrée. 33, 34

Relancer les workers via l’API d’administration, --watch ou MAX_REQUESTS ne remplace pas le moteur PHP chargé par le serveur. Pour corriger les CVE de Zend, il faut déployer une image ou un binaire FrankenPHP intégrant les versions corrigées de PHP, puis redémarrer le processus serveur ; dans une compilation avec PHP partagé, il faut aussi mettre à jour la bibliothèque PHP effectivement chargée. Les images et binaires officiels FrankenPHP 1.13.2 embarquaient déjà ces correctifs. 27, 31

La compatibilité reste aussi conditionnée aux extensions : la documentation FrankenPHP cite notamment New Relic, PCOV et certaines compilations d’Imagick avec OpenMP. Elle recommande les builds glibc plutôt que musl pour la production. Les solutions voisines — RoadRunner avec ses processus CLI persistants, OpenSwoole et ses coroutines, ou le jeune OxPHP écrit en Rust autour de Zend — déplacent autrement ces compromis. 33, 35, 36, 37, 38

Pourquoi PHP reste-t-il partout ? Et qui paie pour cela ?

W3Techs détecte PHP sur 69,8 % des sites dont le langage serveur est connu au 1er octobre 2026, contre 73,4 % au 1er octobre 2025. JavaScript côté serveur progresse de 5,0 à 7,6 % sur les mêmes relevés mensuels. Ce sont des proportions de sites détectables, pas du trafic ni la répartition de tous les serveurs. 39

WordPress représente, de son côté, environ 39,6 % des sites étudiés. Composer et Packagist comptent plus de 469 000 paquets et 200 milliards d’installations cumulées, chiffres qui englobent évidemment CI et déploiements répétés. Entre WordPress, Drupal, PrestaShop, Magento et les applications métiers, le coût d’un changement de plateforme serait immense. 40, 41

PHP reste adapté à un besoin très répandu : recevoir une requête HTTP, interroger une base de données et renvoyer une page ou du JSON. L’installation est simple, l’hébergement largement disponible, le modèle sans état applicatif persistant entre requêtes facile à exploiter. Le langage, lui, a continué à évoluer. Dans l’enquête Stack Overflow 2026, 17,7 % de 14 099 répondants déclarent avoir beaucoup utilisé PHP : ce petit panel volontaire mesure des développeurs, pas le nombre de sites installés. 42

Le parc installé vieillit aussi. Fin octobre, W3Techs identifie encore 26,6 % de PHP 7 et 7,7 % de PHP 5 parmi les sites PHP : plus d’un tiers sur des branches privées de correctifs officiels. Les backports fournis par certaines distributions ou mainteneurs sont possibles, mais ne changent pas le fait que le risque réel dépend aussi du parc installé et de sa maintenance, pas uniquement du langage qui implémente Zend. 43, 44

La sécurité de PHP dépend aussi des moyens consacrés à sa maintenance. Les premiers signes de CVE-2026-109618 ont été identifiés pendant les suites d’un audit Quarkslab financé en 2024, mais la recherche d’un correctif a stagné des mois : compatibilité des extensions, risques de déni de service, absence de consensus et manque de ressources. La PHP Foundation parle elle-même d’un échec structurel. 1

En 2025, la fondation a reçu 730 534 dollars de contributions, pour 784 376 dollars de dépenses et 11 développeurs sous contrat à temps partiel ou plein fin décembre. Ce n’est ni toute l’équipe PHP ni tout le financement indirect de son écosystème, mais c’est un ordre de grandeur étonnant pour un logiciel si répandu. 45

L’IA accélère désormais les deux côtés : l’audit Calif, les signalements indépendants d’OpenAI et Wiz ont contribué à mettre en évidence l’exploitabilité du problème de 2024 ; la Foundation utilise aussi des outils d’assistance pour vérifier les rapports. L’afflux de découvertes rend encore plus nécessaire un travail humain de tri, de correction et de revue. 1

Le plus dur n’est pas d’écrire un nouveau PHP. C’est d’être PHP.

Les failles d’octobre 2026 donnent de bonnes raisons de chercher des moteurs plus sûrs pour la mémoire. L’histoire de HHVM rappelle toutefois le coût de la compatibilité. KPHP assume ses restrictions ; WordPress Playground transporte Zend en WebAssembly ; FrankenPHP modernise l’exécution sans réinventer les règles du langage ; php-rust essaie de faire les deux à la fois.

Toutes les vulnérabilités de PHP ne sont pas des bugs mémoire. CVE-2024-4577, exploitée sur certaines installations Windows en mode CGI, relevait d’une injection d’arguments ; une réécriture en Rust n’aurait pas automatiquement empêché ce problème. 46

Un nouveau moteur doit préserver des milliers de comportements historiques, les extensions et la simplicité du déploiement, tout en apportant des améliorations de sécurité et d’exploitation. Le moteur actuel, lui, a besoin de moyens suffisants pour être audité, corrigé et maintenu.

Un moteur alternatif finira peut-être par s’imposer. Il pourrait aussi, comme HHVM, surtout pousser PHP à progresser. Le plus dur n’est pas d’écrire un nouveau PHP. C’est de réussir à être PHP.

---

Sources et bibliographie

Sources consultées ou revérifiées le 27 octobre 2026. Les mesures des projets, annonces de sécurité et parts de marché correspondent à cette date ou à la date explicitement indiquée.

1. PHP Foundation, Today’s PHP Security Release, and How We’re Strengthening PHP Security, 21 octobre 2026.
2. CERT-FR / ANSSI, Alerte CERTFR-2026-ALE-014, mise à jour du 26 octobre 2026.
3. Le Parisien, Préfectures, impôts… sites en maintenance, 21 octobre 2026.
4. Reuters, Factbox — Governments, companies take websites offline over PHP flaws, 22 octobre 2026.
5. watchTowr, PHP2Shell FAQ, signalements d’exploitation et KEV, mis à jour le 26 octobre 2026.
6. PHP Security Team, CVE-2026-109618 : RCE via OOM corruption, 21 octobre 2026.
7. PHP Security Team, CVE-2026-109619 : RCE via stale global state, 21 octobre 2026.
8. PHP.net, Annonce CVE-2026-115560 : session upload progress, 23 octobre 2026.
9. PHP.net, Session runtime configuration — upload progress activé par défaut, documentation consultée en octobre 2026.
10. Francesco Tinti, Dépôt php-rust, architecture, contributions et commits, consulté le 27 octobre 2026.
11. php-rust, COVERAGE.md — fonctions et tests exécutés, mesures du 16 septembre 2026.
12. php-rust, NEXT_SESSION_WORDPRESS.md — journal de sessions et performances, octobre 2026.
13. php-rust, Issue #6 — défaut de validation filter_var(), 25 octobre 2026.
14. php-rust, PR #7 — correctif proposé pour EMAIL et DOMAIN, 25 octobre 2026.
15. wudi, php-rs — autre interpréteur Rust expérimental, consulté en octobre 2026.
16. PHP.net, PHP 7.0.0 — annonce de sortie, décembre 2015.
17. Symfony, Symfony 4: End of HHVM Support, mai 2017.
18. HHVM, Ending PHP Support, and the Future of Hack, septembre 2018.
19. HHVM, HHVM 4.0.0, février 2019.
20. Meta Engineering, Full-stack HHVM optimizations for GenAI, mai 2025.
21. HHVM, Project Update and OSS Support Changes, octobre 2023.
22. ext-php-rs, Guide officiel : extensions Zend en Rust, consulté en octobre 2026.
23. VK, KPHP — compilateur PHP vers C++.
24. PeachPie, Compilateur PHP vers .NET.
25. WordPress, Playground: compiling PHP to WebAssembly.
26. FrankenPHP, Documentation générale.
27. FrankenPHP, Worker mode.
28. Tideways, Testing FrankenPHP Classic Mode against PHP-FPM, septembre 2025.
29. FrankenPHP Security, CVE-2026-24894 / GHSA-r3xh-3r3w-47gp — fuite de $_SESSION en mode worker, février 2026.
30. FrankenPHP Security, GHSA-4gfw-9v29-gp9h — état libxml entre requêtes, 21 octobre 2026.
31. FrankenPHP, Release 1.13.2 — PHP2Shell et correctifs propres à FrankenPHP, 21 octobre 2026.
32. php-src, Commit 31c0ea7d — Avoid state corruption via bailout, 18 octobre 2026.
33. FrankenPHP, Known issues : hard memory limit, extensions.
34. php-src, Issue #24492 — OOM regression in sprintf/pack/bin2hex, octobre 2026.
35. FrankenPHP, Performance optimization : glibc versus musl.
36. RoadRunner, Site officiel et architecture.
37. OpenSwoole, Site officiel.
38. OxPHP, Dépôt expérimental en Rust autour de Zend.
39. W3Techs, Historique mensuel des langages serveur, 1er octobre 2025 et 1er octobre 2026.
40. W3Techs, Part de marché des CMS, octobre 2026.
41. Packagist, 15 years of Packagist: Over 200 billion installs, 29 septembre 2026.
42. Stack Overflow, Developer Survey 2026 — Programming languages, 14 099 répondants.
43. W3Techs, PHP : versions déployées, 27 octobre 2026.
44. PHP.net, Dates de fin de support des branches PHP.
45. PHP Foundation, Impact and Transparency Report 2025, mai 2026.
46. CERT-EU, CVE-2024-4577 : injection d’arguments PHP-CGI Windows, juin 2024.