PHP2Shell et Fragnesia : deux failles PHP au catalogue KEV, enchaînées à une élévation root

Au 2 novembre 2026, les échéances que le catalogue de la CISA associe à ces trois fiches sont dépassées. Le flux du Known Exploited Vulnerabilities Catalog fixe au 29 octobre le délai des deux failles PHP, et au 31 octobre celui de la faille du noyau. L'alerte du 28 octobre rappelle que la directive BOD 26-04 s'impose aux agences civiles fédérales américaines, et invite les autres organisations à traiter ces entrées en priorité.

Deux failles PHP, un nom, quatre versions

Le 21 octobre 2026, le projet PHP a publié un avis. Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux vulnérabilités critiques qui peuvent permettre une exécution de code à distance sans authentification.

CVE-2026-109618, aussi référencée GHSA-w8hw-w9fx-j79w, porte sur une corruption liée au manque de mémoire. Le traitement d'une allocation qui échoue peut interrompre PHP alors que des données internes de requête ne sont qu'en partie initialisées. Le nettoyage peut ensuite les traiter comme valides. CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, porte sur un état interne de requête qui peut survivre à la libération de sa mémoire. Une requête ultérieure, sur le même processus worker, peut s'en servir avant que l'initialisation habituelle ne le remette à zéro.

L'avis vise toute installation qui sert des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Il place le risque le plus haut sur mod_php : un exploit démontré permet à une requête non authentifiée de déclencher l'attaque avant le code de l'application.

La veille, la même archive annonçait la sortie pour le 21 octobre à 14:00 UTC et indiquait que les deux vulnérabilités étaient notées CVSS v4.0 9.2. Les quatre notes de version du 21 octobre écrivent : « There are no complete mitigations, updating is the only safe choice. »

La CISA, dans une alerte publiée le 21 octobre et mise à jour le 26, nomme l'ensemble « php2shell » et reprend la même liste de versions. Le flux JSON du catalogue, lu le 2 novembre 2026, date l'ajout de CVE-2026-109618 et de CVE-2026-109619 au 26 octobre, avec une échéance au 29 octobre. Les deux fiches marquent l'usage en rançongiciel « Unknown » et un triage forensique « Yes ». La première décrit une corruption mémoire en cas de manque de mémoire, permettant une exécution de code à distance sans authentification. La seconde décrit un état interne de requête périmé, avec le même résultat.

La phrase du catalogue sur Fragnesia

L'alerte du 28 octobre annonce deux ajouts, sur la base d'éléments d'exploitation active : CVE-2026-41709, chez Broadcom VMware ESX, et CVE-2026-46300, décrite comme une initialisation de variable manquante dans le noyau Linux. Le texte de l'alerte s'arrête à ces intitulés.

La fiche du catalogue va plus loin. Sa description courte dit que le noyau peut modifier des données adossées au cache de pages : le marqueur de fragment partagé n'est pas conservé lors de la fusion de tampons de socket, et le traitement ESP déchiffre alors des fragments partagés sur place. La phrase qui suit est celle-ci : « This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root. »

La fiche date l'ajout au 28 octobre 2026 et l'échéance au 31 octobre. L'usage en rançongiciel est « Unknown ». Le triage forensique est « Yes ». Le CWE enregistré est CWE-456. Les notes renvoient à huit commits du dépôt stable du noyau, sur git.kernel.org, à la directive BOD 26-04 et à la fiche NVD. Le message de ces commits n'a pas été lu : le site a renvoyé une page anti-robot.

Red Hat documente la même CVE dans le sous-système XFRM ESP-in-TCP. Un attaquant local peu privilégié peut écrire des octets arbitraires dans le cache de pages de fichiers en lecture seule, y compris des fichiers système sensibles, remplacer des binaires privilégiés et obtenir les droits root. L'éditeur classe l'impact « Important », parce que l'exploitation exige un accès local. La page affiche un score CVSS v3.1 de 7,8, vecteur CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, et l'attribue à la fois à Red Hat, au NVD et à cve.org. Le suivi Bugzilla 2477015 nomme la faille « Fragnesia » et la présente comme une variante de Dirty Frag. La même page mentionne CWE-123.

BleepingComputer, le 29 octobre 2026, reprend la phrase du catalogue sur les webshells et le root. Sergiu Gatlan écrit que l'agence n'a pas détaillé les attaques en cours, et qu'un porte-parole, interrogé le jour même, n'était pas en mesure d'en dire davantage sur un enchaînement.

Les décomptes qui circulent ensuite divergent. La FAQ de Tenable, mise à jour le 28 octobre, attribue à Dream Research une campagne qui aurait obtenu un accès root sur 24 pare-feu exposés, puis sur un serveur interne de gestion. Certains de ces systèmes, selon la formule reprise par Tenable, « appeared to belong to a US government-affiliated environment ». Tenable précise ne pas avoir confirmé cette activité. BleepingComputer, en citant les mêmes chercheurs, parle de 25 serveurs aux États-Unis, au Japon, à Taïwan et en Corée du Sud, dont trois dans un environnement affilié au gouvernement américain. Le rapport Dream n'a pas été ouvert. Aucun de ces deux totaux ne figure dans la fiche CISA.

Tenable attribue aussi à Amazon Threat Intelligence une tentative d'exploitation de php2shell le 17 octobre 2026, contre le réseau de leurres MadPot, quatre jours avant les correctifs, puis des tentatives plus nombreuses. Le compte rendu d'Amazon n'a pas été ouvert.

Ce que les correctifs PHP couvrent

Le projet PHP ne publie plus de mises à jour pour PHP 8.1 et les branches plus anciennes. L'avis du 21 octobre précise que des distributions et des éditeurs de support long ont reçu les correctifs à l'avance, et que l'équipe de sécurité a fourni des rétroportages sources minimaux pour PHP 7.4, PHP 8.0 et PHP 8.1, à l'usage de ceux qui compilent eux-mêmes ou qui n'ont pas ce type d'éditeur. Pour les autres installations anciennes, l'avis dit de passer à une version prise en charge.

La page des versions prises en charge, lue le 2 novembre 2026, commence à PHP 8.2. Chaque branche reçoit deux ans de support actif, puis deux ans limités aux correctifs de sécurité critiques. PHP 8.2 est dans cette seconde période : le support de sécurité court jusqu'au 31 décembre 2026. La note de la version 8.2.35 le répète. PHP 8.3 reste couvert pour la sécurité jusqu'au 31 décembre 2027, PHP 8.4 jusqu'au 31 décembre 2028, PHP 8.5 jusqu'au 31 décembre 2029.

La CISA demande aux organisations qui ne peuvent pas mettre à jour tout de suite, ou qui restent sur PHP 8.1 ou une version plus ancienne, de retirer les systèmes concernés du réseau jusqu'à correction ou mise à jour. Un pare-feu applicatif peut fournir une protection dans l'intervalle. L'alerte le place parmi les mesures d'attente.

Quand la mise à jour n'est pas immédiate, l'avis PHP écrit qu'une mise à jour reste la seule solution complète. Les mesures qu'il liste réduisent l'exposition à des chemins précis. Pour CVE-2026-109618, il cite memory_limit=-1, posé de façon à ce que l'application ne puisse pas le réécrire, et un post_max_size bas : 8 Mo sans envoi de fichier, 32 Mo s'il en faut. Pour CVE-2026-109619, il cite session.upload_progress.enabled=0, appliqué avant l'analyse de la requête, avec redémarrage de chaque worker, et, sur PHP 8.5, fatal_error_backtraces=0. Ces réglages visent des chemins confirmés. L'avis écrit qu'ils en laissent d'autres ouverts.

Le même 21 octobre, la note sur PHP 8.6.0 RC4 indique que cette préversion contient aussi les correctifs, et qu'elle ne doit pas servir en production.

W3Techs, au 2 novembre 2026, mesure PHP sur 69,1 % des sites dont le langage côté serveur est identifié. Parmi les sites où PHP est reconnu, la version 8 représente 66,0 %, la version 7 26,3 %, la version 5 7,6 % et la version 4 0,1 %. Le relevé des sous-versions de PHP 8, le même jour, place PHP 8.3 à 35,0 %, PHP 8.2 à 27,0 %, PHP 8.1 à 14,6 %, PHP 8.4 à 12,5 %, PHP 8.0 à 5,6 % et PHP 8.5 à 5,4 %. Ces six lignes totalisent environ 100 % et décrivent donc la répartition interne de la version 8. W3Techs n'imprime pas une part unique pour « PHP 8.1 ou plus ancien ». En rapportant PHP 8.0 et PHP 8.1, soit 20,2 % de la version 8, aux 66,0 %, puis en ajoutant les versions 7, 5 et 4, soit 34,0 % des sites PHP, le rapprochement donne environ 47 % des sites PHP mesurés. Ce pourcentage est un calcul fait à partir des deux tableaux. Il ne dit pas qui a installé le correctif de point : une branche 8.3 peut encore être antérieure à 8.3.36.

Inventaire, noyau, et ce que les fiches ne nomment pas

L'alerte CISA du 21 octobre demande d'inventorier toute installation PHP, y compris lorsque le langage est embarqué dans un autre logiciel, puis d'appliquer le correctif en commençant par les systèmes exposés à Internet. Elle renvoie à l'avis PHP. Elle demande aussi de surveiller les processus worker PHP qui lancent un shell ou téléchargent des outils. Une règle SIGMA est mentionnée pour les journaux. Son texte n'a pas été ouvert.

Pour CVE-2026-46300, l'action exigée par le catalogue est d'appliquer les mesures du fournisseur, dans le cadre de BOD 26-04, ou de cesser d'utiliser le produit si aucune mesure n'existe. Red Hat renvoie au bulletin RHSB-2026-003 pour le contournement. Ce bulletin n'a pas été ouvert. La page CVE rappelle que l'exploitation suppose un accès local. Dans la phrase du catalogue, cet accès est celui que l'exécution de code PHP peut donner au compte du worker, avant le passage en root.

Les trois fiches marquent un triage forensique. Dans les champs lus le 2 novembre, le catalogue ne publie ni liste d'indicateurs, ni nom de webshell, ni famille d'attaquants. La preuve d'exploitation retenue ici est l'inscription elle-même, que l'alerte du 28 octobre motive par des éléments d'exploitation active, et la phrase de la fiche 46300 sur l'enchaînement. Les totaux de serveurs ou de pare-feu restent ceux des reprises de presse.