Le mercredi 21 octobre 2026 à 14 h UTC, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur l'échelle CVSS v4.0, qui peuvent permettre une exécution de code à distance sans authentification. Selon l'éditeur, toutes les installations qui servent des requêtes web sont concernées, sous PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed, et le risque est jugé le plus élevé avec mod_php.

Le jour même, le CERT-FR a mis à jour son alerte CERTFR-2026-ALE-014 et le ministère de l'Intérieur a fermé ses sites exposés, préfectures comprises. La chronologie publiée par la PHP Foundation montre que le défaut à l'origine de la première faille était identifié depuis 2024, sans vecteur d'exploitation connu. Cet été, des chercheurs, dont certains revendiquent l'usage de modèles d'IA, en ont démontré la gravité en quelques semaines.

Un défaut repéré lors de l'audit de 2024, resté sans correctif

Dans un billet publié le 21 octobre, la PHP Foundation retrace l'histoire de CVE-2026-109618. En 2024, PHP passe son premier audit de sécurité externe depuis des années, financé par la Sovereign Tech Agency allemande, organisé par l'OSTIF et réalisé par la société française Quarkslab. En corrigeant l'un des problèmes signalés, un développeur du cœur de PHP repère les premiers signes d'un défaut lié aux erreurs d'épuisement de la mémoire (out-of-memory). Une exploitation est alors théorisée, sans vecteur concret.

La correction bute ensuite sur des arbitrages. Chaque approche envisagée cassait la compatibilité, ouvrait un risque de déni de service ou imposait des modifications à de nombreuses extensions tierces, impossibles à coordonner. L'équipe de sécurité, qui décide au consensus, a vu le chantier « caler et redémarrer à plusieurs reprises pendant des mois ». La fondation écrit que « le retard était un échec structurel », dû au mode de décision de l'équipe et à son manque de moyens (citations traduites de l'anglais).

Calif, OpenAI et Wiz : l'été où l'exploitation a été démontrée

Dans le cadre du programme Patch the Planet, la société Calif commence un audit de PHP le 30 juillet 2026. Le 11 août, son chercheur Ryan A. signale une exécution de code à distance inconditionnelle, de même cause racine que le défaut de 2024. OpenAI, dont la fondation crédite l'équipe Codex Security, rapporte indépendamment la même cause le même jour. Wiz Research suit le 24 août avec d'autres vecteurs d'attaque, OpenAI à nouveau le 18 septembre. À partir du 11 août, écrit la fondation, la correction devient la priorité de toute son équipe sécurité.

Wiz détaille dans son billet « PHP2Shell » la place des modèles dans ses travaux. L'équipe dit avoir utilisé son outil Wiz Atlas, Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI. Sa chronologie place la découverte de la première faille au 19 août, l'exécution de code confirmée le 20 août sur Drupal et le 21 sur WordPress, le signalement à PHP le 24. Démontrer l'exploitabilité de ces défauts, présents dans le code depuis plus de dix ans, exigeait selon Wiz une chaîne d'étapes « à la limite de ce que des chercheurs humains pouvaient pratiquement accomplir ». Avec les modèles, toujours selon l'entreprise, un seul chercheur a bouclé en une semaine ce qui aurait demandé des mois à une équipe de premier plan.

La fondation chiffre aussi l'afflux de signalements, avec 15 CVE publiées depuis le 1er juillet et plus de 100 signalements écartés car invalides, en double ou non reproductibles. PostgreSQL connaît une hausse comparable, avec 44 failles corrigées en 2026 contre 7 en 2025.

Une divulgation coordonnée perturbée par une fuite

La sortie était prévue le 22 octobre. Le 20 octobre vers 15 h UTC, les deux identifiants CVE commencent à circuler sur des forums et des réseaux sociaux, avec une heure de sortie erronée et un score CVSS faux de 10. Aucun détail technique n'a fuité, selon la fondation. PHP avance sa pré-annonce, publiée à 19 h 30 UTC, et la sortie au 21 octobre. Calif met ensuite en ligne par erreur une vidéo de sa preuve de concept : retirée, elle a été recopiée et a, selon la fondation, contribué à accélérer le développement de preuves de concept. Le 21 octobre à 7 h 41 UTC, Chainguard publie des images intégrant le correctif plus de six heures avant la sortie, ce que la fondation qualifie de rupture unilatérale de l'embargo.

Isoler puis migrer : la consigne de l'Anssi

Le CERT-FR liste comme affectées toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x, ainsi que les branches 8.2 à 8.5 antérieures aux versions corrigées. Pour les branches que l'éditeur ne maintient plus, il recommande d'isoler les équipements puis de migrer vers une version maintenue et corrigée. Les contournements provisoires qu'il mentionne, en configuration de PHP ou sur un pare-feu applicatif, ne sont « pas qualifiés » par le CERT-FR. Le projet PHP précise qu'aucune mesure d'atténuation n'est complète et seule la mise à jour règle le problème.

Dans une communication du 21 octobre reprise par Global Security Mag, l'Anssi indique que plus de 600 000 serveurs utilisent PHP sur l'Internet français et rappelle que le CERT-FR a recommandé, lorsque c'est possible, la mise hors ligne des serveurs concernés jusqu'à l'application du correctif. Le ministère de l'Intérieur a procédé, à la demande de l'agence, « à la mise en maintenance préventive de l'ensemble de ses sites internet exposés à une vulnérabilité critique de sécurité », selon une déclaration du ministère rapportée par l'AFP. Selon Actu17, certains sites de préfectures ne répondaient plus dès 14 h, heure de Paris, environ deux heures avant la sortie du correctif.

Le 22 octobre à 8 h 33, heure de Paris, le site de la CNIL renvoyait une page « Le site de la CNIL est actuellement en maintenance », impots.gouv.fr indiquait être « actuellement en maintenance » et le site de la préfecture de la Seine-Saint-Denis affichait « Maintenance en cours ». Aucune de ces pages ne mentionne PHP.

Des tentatives d'attaque observées, aucune intrusion confirmée

Cloudflare dit avoir observé du trafic d'attaque visant ses clients, et des attaquants modifier leurs requêtes pour contourner ses règles de filtrage, actives par défaut depuis le 21 octobre à 3 h 02 UTC. La PHP Foundation, qui a examiné les preuves de concept apparues après la fuite, n'avait identifié aucun exploit fonctionnel au moment de la publication. Le 22 octobre à 8 h 35, heure de Paris, les deux CVE ne figuraient pas au catalogue des vulnérabilités exploitées de la CISA, dans sa version du 21 octobre à 14 h 04 UTC. À cette date, aucune de ces sources ne fait état d'une intrusion réussie.

Pour les DSI, les versions hors support deviennent le maillon faible

L'épisode fragilise une hypothèse sur laquelle reposent beaucoup de politiques de correctifs : un défaut connu sans vecteur d'exploitation démontré peut attendre. Chez PHP, celui-ci a attendu de 2024 à l'été 2026 faute d'arbitrage. Entre le 11 et le 24 août, trois équipes l'ont signalé, dont deux avec une exécution de code démontrée, et Wiz, qui revendique l'usage de modèles d'IA, a confirmé une exécution de code sur Drupal le lendemain de sa première découverte. ActuIA a relevé des signaux voisins ces dernières semaines, de l'exploit de failles connues reproduit en 28 minutes par Claroty au pirate qui a percé plus de 100 entreprises avec des agents d'IA.

Les branches maintenues ont reçu leur correctif le jour de la divulgation, et les distributions l'avaient en avance. Le risque principal concerne les serveurs encore en PHP 8.1 ou antérieur en production. Le projet PHP ne les met plus à jour ; vu la gravité, son équipe de sécurité a tout de même fourni des rétroportages minimaux pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent depuis les sources, et certains éditeurs de support long terme publient leurs propres correctifs. Pour les autres, la consigne du CERT-FR reste l'isolement puis la migration, un chantier qui ne se boucle pas dans le délai qu'a laissé cette divulgation.

La PHP Foundation demande aux entreprises, hébergeurs et administrations qui reposent sur PHP de financer ses équipes. La sécurité du moteur dépend encore, écrit-elle, d'« un petit groupe de développeurs financés par la fondation et d'un peu d'aide bénévole ».

Nos articles remonteront en priorité dans « À la une » de Google.