Deux failles, une publication d’urgence
Le projet PHP a publié quatre versions d’urgence le 21 octobre — 8.5.12, 8.4.27, 8.3.36 et 8.2.35 — qui corrigent deux vulnérabilités notées chacune 9,2 sur l’échelle CVSS v4.0 et permettant l’exécution de code à distance sans authentification. Les mainteneurs ont publié en même temps un avis demandant aux exploitants de mettre à jour sans attendre.
La première, CVE-2026-109618, est un bug de gestion de mémoire. PHP utilise longjmp() pour quitter le contexte courant lorsqu’il manque de mémoire, et l’avis décrit des cas où la mémoire de la requête est atteignable avant d’être entièrement initialisée. Si une allocation échoue à cet instant, la sortie anticipée laisse cette mémoire invalide et la fermeture de la requête peut la lire ou s’y brancher. L’avis indique qu’un attaquant peut atteindre ce chemin par l’analyse multipart — un en-tête content-length manquant, un excès d’en-têtes de partie, ou de nombreux contrôles de fichier vides aux noms de champ imbriqués — et que cela peut mener à une exécution de code à distance sous le compte du processus web.
La seconde, CVE-2026-109619, est un bug d’état résiduel : un état interne appartenant à une requête peut survivre à la libération de sa mémoire, si bien qu’une requête ultérieure traitée par le même processus peut suivre ces références pendantes.
L’avis de PHP indique que le risque est le plus élevé pour mod_php, mais que toutes les installations servant du web sont concernées, en citant PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. L’avis GitHub est plus précis sur l’avancée des travaux : mod_php et FrankenPHP y sont décrits comme les plus directement exposés, tandis que FPM est jugé exposé d’après l’analyse du code source, sans qu’un exploit complet ait été démontré.
Là où l’IA intervient
OpenAI a publié son propre récit le même jour. Dans un billet consacré à ce qu’elle appelle Patch the Planet, l’entreprise dit que la société de sécurité Calif a identifié une faille critique avec GPT‑5.6 Sol, et que Wiz a découvert et signalé les deux vulnérabilités de son côté. Les mainteneurs de PHP ont dirigé les correctifs et la publication.
La liste des crédits de l’avis GitHub correspond à ce récit : elle nomme quatre rapporteurs, dont des identifiants suffixés -wiz et -oai, et quatre développeurs PHP qui ont construit la remédiation.
Le cadrage d’OpenAI est que le secteur a eu de la chance sur le calendrier. « À notre connaissance, l’IA de pointe a trouvé ces vulnérabilités avant les attaquants », écrit l’entreprise, « ouvrant une fenêtre du défenseur permettant aux mainteneurs et aux fournisseurs de sécurité de préparer correctifs et protections avant la divulgation ». Elle qualifie la paire de « l’un des problèmes de sécurité les plus marquants de mémoire récente » au vu de la diffusion de PHP, et dit s’attendre à ce que de telles découvertes « augmentent fortement dans les mois à venir ». En parallèle, elle a engagé un milliard de dollars d’accès subventionné à son produit de sécurité Daybreak pour les organisations aux moyens limités, et dit avoir contacté la Super Intelligence Force de la Maison-Blanche, l’Office of the National Cyber Director et la CISA avant la divulgation.
La version de Cloudflare est moins confortable
Cloudflare, qui a participé à la même réponse coordonnée, a donné un nom à la paire — php2shell — et a publié sa propre analyse, affirmant que tout serveur web exécutant PHP 5.4 ou une version ultérieure est concerné. L’entreprise dit avoir commencé à écrire des règles de pare-feu applicatif début octobre et les avoir activées environ neuf heures avant la divulgation publique, les offres gratuites et payantes étant protégées par défaut à partir de 03h02 UTC le 21 octobre.
Elle dit aussi observer du trafic d’attaque contre ses clients, et que les attaquants ont modifié leurs charges utiles pour tenter de contourner les règles, ses analystes suivant les volumes de correspondances pour pister les mutations. Cela ne contredit pas l’affirmation d’OpenAI selon laquelle les défenseurs ont trouvé les bugs en premier, mais réduit nettement la fenêtre : au matin de la divulgation, quelqu’un essayait déjà.
Ce que les exploitants doivent faire
La mise à jour est le seul correctif complet. L’avis de PHP énumère des mesures provisoires — fixer memory_limit=-1 via php_admin_value plutôt que ini_set(), baisser post_max_size, désactiver session.upload_progress et, sur 8.5, mettre fatal_error_backtraces=0 — et précise qu’aucune ne rend une installation sûre. Il met aussi en garde contre RLIMIT_AS et RLIMIT_DATA, qui peuvent déclencher le chemin vulnérable.
PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour en amont : ceux qui restent sur ces branches dépendent d’un rétroportage de leur distribution. Les distributions Linux et les fournisseurs de support à long terme ont reçu les correctifs à l’avance. PHP 8.2 atteint sa fin de vie le 31 décembre 2026.
Cloudflare cite W3Techs pour le chiffre selon lequel PHP fait tourner près de 70 % des sites web. Le nombre à surveiller dans les quinze prochains jours n’est pas le score de gravité mais le taux de correction sur l’hébergement mutualisé, où celui qui applique le correctif n’est presque jamais le propriétaire du site.
