php2shell: surface, hunting et détection red team

php2shell désigne le couple CVE-2026-109618 et CVE-2026-109619, deux failles critiques du runtime PHP publiées le 21 octobre 2026 qui, dans les scénarios confirmés par les avis officiels, permettent une RCE PHP sans authentification sur les installations qui servent des requêtes HTTP.

En outre, l’avis officiel dans les archives 2026 de php.net place le risque dans le moteur qui traite les requêtes web, et non dans un plugin de CMS. L’angle de ce texte porte donc sur la surface, l’inventaire en pentest autorisé et le hunting défensif. En contrepartie, l’article frère sur basilisk couvre la check-list opérationnelle de correctif, ce qui évite au red team de cannibaliser le guide de remédiation tout en livrant un modèle de menace utile.

Ce que l’anatomie du php2shell révèle dans les deux failles

Le CVE-2026-109618 décrit une corruption liée à un out-of-memory au milieu de l’initialisation des données internes de la requête, tandis que le CVE-2026-109619 décrit un état global qui survit à la mémoire libérée et est réutilisé par la requête suivante dans le même worker. Ensemble, ils forment la faille mémoire PHP surnommée php2shell.

Comment l’OOM laisse la requête dans un état invalide

Dans l’advisory GHSA-w8hw-w9fx-j79w, l’équipe de sécurité de PHP explique le rôle de longjmp(). Le moteur utilisait ce mécanisme pour abandonner la requête lorsque la mémoire s’épuisait. À certains points, une partie de la structure de la requête était déjà atteignable, alors qu’elle n’était pas encore pleinement initialisée. Si une allocation échouait à ce moment, le chemin de nettoyage pouvait traiter des données invalides comme valides, et le moteur poursuivait en lisant ou en ramifiant sur elles.

Comment l’état stale traverse les requêtes dans le même worker

Le second identifiant, CVE-2026-109619, figure dans le GHSA-6wmf-4rv5-p3rp. Il traite des champs globaux du worker qui pointent vers la mémoire d’une requête. Cet état doit être réinitialisé avant la libération du heap. Lorsqu’une erreur fatale, un diagnostic ou un chemin de session et d’upload interrompt le flux au mauvais moment, le pointeur global demeure. Ensuite, la requête suivante dans le même processus persistant peut consommer cette valeur. En classe de bug, le premier CVE combine une gestion défaillante d’une condition exceptionnelle avec l’usage d’un état non initialisé. Le second est un use-after-free classique entre requêtes.

Où les sources divergent sur le périmètre et le score

Des chercheurs et des couvertures cloud, dont Cloudflare, situent des chemins exploitables depuis PHP 5.4 dans certaines configurations. L’avis officiel et les GHSA listent pourtant comme corrigées les lignes 8.2.35, 8.3.36, 8.4.27 et 8.5.12, avec aussi des backports minimaux de source pour 7.4, 8.0 et 8.1. L’étendue depuis 5.4 est une affirmation de chercheurs et de rapports tiers. Ce n’est pas un inventaire clos par le CNA de PHP pour chaque release héritée.

Le score publié par l’équipe PHP et repris par CERT-EU, NHS England et Datadog est CVSS v4.0 9.2 pour les deux. Un 10.0 a circulé dans la fuite pré-divulgation. De plus, le NVD et des fournisseurs comme Red Hat peuvent publier des vecteurs v3.1 différents. En inventaire, notez la source du score et ne mélangez pas les échelles entre v3.1 et v4.0.

En pratique, ce que je vois le plus souvent en engagement, c’est que l’équipe traite les deux CVE du php2shell comme un seul ticket de correctif, ce qui efface la différence de précondition. Qui sépare l’OOM dans le nettoyage de la requête de la réutilisation du worker place mieux les capteurs et priorise mieux lorsque l’inventaire montre mod_php versus FPM.

Quelles préconditions et surfaces d’attaque comptent vraiment

La surface confirmée par php.net couvre toute installation PHP qui sert des requêtes web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est décrit comme plus élevé pour mod_php, avec un exploit démontré dans lequel une requête sans authentification déclenche l’attaque avant tout code de l’application.

Comment la SAPI et le worker persistant changent la fenêtre

La CISA, dans l’alerte du 21 octobre 2026, rappelle que toutes les installations qui répondent en HTTP entrent dans le périmètre. Elle demande aussi un inventaire là où PHP est embarqué dans un produit tiers. Les workers persistants changent la donne du CVE-2026-109619, car le producteur et le consommateur de l’état obsolète doivent partager le même processus.

Dans les SAPI qui tuent le fils après un échec d’initialisation, le chemin du CVE-2026-109618 peut se rétrécir. L’advisory de l’OOM le dit explicitement pour le FPM, qui termine le fils lorsque le startup échoue et évite ainsi de consommer l’état invalide sur ce rameau. Une analyse de source de l’advisory pointe pourtant le FPM comme sensible à d’autres moments. Tous les rameaux n’ont pas d’exploit complet démontré. La PHP Foundation confirme aussi la RCE sur des chemins d’application sous FPM. Un processus par requête réduit la fenêtre de l’état stale entre requêtes, sans annuler à lui seul l’OOM dans le nettoyage si l’arrêt voit encore une mémoire partielle.

Ce que les mitigations partielles bloquent et ce qu’elles laissent ouvert

Une autre précondition pratique est l’exposition du parsing automatique du corps, du multipart et des chemins de session et de diagnostic qui s’exécutent tôt. Les mitigations partielles citées par php.net, comme memory_limit=-1 administratif pour l’OOM, bloquent des chemins confirmés. Il en va de même pour session.upload_progress.enabled=0 avec redémarrage des workers pour l’état stale. Elles laissent des variantes ouvertes et ne rendent donc pas l’installation sûre face au php2shell. Des CMS courants apparaissent dans des démos de chercheurs, mais la faille est celle du runtime. L’authentification d’application n’est pas un contrôle pour le rameau qui se déclenche avant le script.

L’erreur qui coûte le plus cher ici est de croire que « nous n’utilisons pas l’upload » ou « il n’y a que du FPM » équivaut à sortir du périmètre du php2shell. En inventaire réel, ce qui décide la priorité, c’est la SAPI, la version du paquet et l’exposition Internet, plus la réutilisation du worker. Le nom du CMS en vitrine décide presque jamais du risque.

Comment la faille mémoire PHP devient exécution de code au niveau conceptuel

En langage de classe de bug, l’attaquant n’a pas besoin de percer la logique de WordPress. Il force le moteur à continuer d’opérer sur des structures qui ne représentent plus une requête valide. Dans le CVE-2026-109618, le nettoyage après OOM lit ou suit des pointeurs et métadonnées incomplets. Avec un contrôle suffisant sur le contenu qui occupe ou presse la mémoire de la requête, cette lecture se transforme en corruption utile. Dans le CVE-2026-109619, un use-after-free entre requêtes permet à la seconde requête d’interpréter des octets façonnés dans la première, ou des octets qui fuient d’autres requêtes du même worker.

Le pont conceptuel jusqu’à la RCE est le même que pour d’autres failles mémoire dans des interpréteurs. La corruption ou la réutilisation d’objets internes devient un détournement de flux ou un appel de fonction sous contrôle de l’attaquant. Les privilèges sont ceux du compte du worker web. La divulgation mémoire, décrite par Wiz, Datadog et par l’advisory de l’état stale comme effet collatéral possible, peut livrer adresses et secrets, ce qui stabilise la chaîne de RCE. Rien de tout cela n’exige un layout public dans ce texte. Le point opérationnel est que l’authentification de l’app et un WAF à signature superficielle ne ferment pas la classe. L’idée qu’il n’y a pas de RCE dans le code de l’application ne ferme pas non plus le php2shell.

Beaucoup pensent que seul un heap overflow classique avec offset publié compte. Ils se trompent presque toujours, parce qu’ici le déclencheur est le chemin d’erreur et le cycle de vie de la requête. En revue de menace, traitez php2shell comme une faille de runtime avec impact shell sous l’utilisateur du serveur web, et non comme un CVE de plugin.

Comment décrire la chaîne d’attaque à haut niveau sans devenir une PoC

À haut niveau, la chaîne du php2shell commence par une ou plusieurs requêtes HTTP spécialement construites contre un endpoint que PHP parse. Pour le CVE-2026-109618, l’objectif conceptuel est de provoquer une panne mémoire ou un abandon à un moment où les structures de la requête sont à moitié prêtes, puis de laisser le nettoyage opérer sur cet état. Pour le CVE-2026-109619, la séquence implique typiquement une requête qui produit un état global résiduel, puis une autre requête, dans le même worker, qui consomme cet état avant un reset complet. Le résultat recherché est du code sous l’utilisateur d’Apache, du FPM ou de la SAPI équivalente.

Les sources publiques divergent sur l’exploitation terrain au 21 octobre 2026. La CISA a déclaré n’avoir pas observé d’exploitation à la publication de son alerte. Cloudflare a rapporté du trafic d’attaque et des mutations de payloads contre des règles déjà actives. Le Centre canadien pour la cybersécurité a parlé d’une PoC disponible sans exploitation active identifiée à cette date. SecurityWeek et watchTowr ont décrit des tentatives sur des capteurs, et dans certains récits le succès restait encore limité. Pour le red team et pour le SOC, l’état sûr consiste à assumer que la fenêtre post-fuite est hostile. Inventaire plus correctif bat le débat de télémétrie tierce sur le php2shell.

Qui a déjà balayé un inventaire de runtime chez un client sait que la chaîne requête anormale, worker sous pression et processus fils inattendu apparaît avant tout webshell élégant. Si l’engagement est autorisé, documentez l’hypothèse et les preuves passives. Ne déclenchez pas la faille en production d’un tiers ni sur un hôte hors RoE.

Comment évaluer l’exposition au php2shell en pentest autorisé

En pentest avec autorisation formelle écrite, l’évaluation correcte du php2shell est l’inventaire et la validation du niveau de correctif, pas le déclenchement de la vulnérabilité. Collectez la version de l’interpréteur et du paquet de la distribution, ainsi que la SAPI en usage, la présence de mod_php, les pools FPM, les conteneurs et appliances qui embarquent PHP. Comparez avec 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Lorsque la ligne est 8.1 ou antérieure, comparez avec l’advisory du fournisseur LTS.

Le NCSC du Royaume-Uni, dans l’alerte sur le problème critique affectant PHP, a demandé l’identification prioritaire des systèmes orientés Internet, ainsi qu’un suivi continu des fournisseurs qui empaquettent le runtime. Validez que la bannière ou le phpinfo exposé correspondent au paquet installé, parce que les proxys et les images anciennes mentent. Dans l’environnement du client sous contrat, privilégiez la lecture de paquet et un redémarrage contrôlé après correctif. Évitez la preuve destructive. Si le périmètre exige une démonstration d’impact, utilisez un laboratoire isolé qui reflète la SAPI et la version. N’utilisez jamais la cible de production d’un tiers. Cherchez les signes d’exposition indirecte, comme les panneaux et produits qui déclarent un PHP embarqué sans offrir de mise à niveau simple.

1. Inventorier les hôtes, conteneurs et appliances avec PHP qui répondent en HTTP, avec preuve de paquet et de SAPI.
2. Comparer la version en exécution avec 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou avec un backport LTS documenté, et marquer l’exposition lorsque le plancher corrigé n’est pas présent.
3. Enregistrer l’exposition réseau, la réutilisation du worker et les contraintes du RoE, sans déclencher OOM ni use-after-free sur la cible de production.

En engagement autorisé, le critère que j’utilise est simple. Version sous le plancher corrigé plus SAPI web égale un constat critique d’exposition au php2shell, avec preuve de paquet et de configuration. Déclencher OOM ou use-after-free sur la cible seulement si le RoE le dit explicitement et si l’environnement est jetable. Sinon, vous mélangez validation et incident.

Quels signaux dans les journaux et indicateurs publics suivre

Les signaux utiles pour le php2shell apparaissent en trois couches. La première est la requête. La deuxième est le journal PHP ou du serveur web. La troisième est le processus. Le matériel Datadog Security Labs sur php2shell décrit la corrélation entre soumissions anormales, erreurs fatales de limite mémoire pendant l’initialisation de la requête et workers qui lancent un shell.

Les erreurs fatales mémoire avant le script entrent dans la même famille d’IOC. Il en va de même pour les redémarrages de fils Apache avec échec de segmentation, ainsi que pour les pics de corps volumineux ou multipart hors baseline. Des processus fils inattendus sous l’UID du serveur web complètent le tableau. La CISA et l’alerte canadienne demandent de surveiller les workers PHP qui lancent des shells, téléchargent des outils ou créent des processus, fichiers, comptes et connexions sortantes atypiques.

La post-exploitation classique reste valide. Nouveaux webshells dans des répertoires inscriptibles, téléchargements par outils réseau depuis le worker, cron ou services systemd créés par l’utilisateur PHP, nouveaux comptes locaux et connexions sortantes atypiques. Aucun signal isolé ne prouve php2shell. Un pic mémoire légitime et un déploiement mal fait génèrent aussi de l’OOM. La force est dans la corrélation temporelle entre anomalie de requête, échec de worker et exécution.

En hunting, le raccourci qui trompe le plus est de ne chasser que des chaînes de webshell connues. Au jour zéro de la divulgation, ce qui apparaît d’abord est souvent du bruit de worker et des fils de shell. Je commencerais par les arbres de processus d’Apache et de FPM, puis je refermerais sur les fichiers liés au php2shell.

Comment penser la détection php2shell avec Sigma et WAF à haut niveau

Les règles de style Sigma pour la détection php2shell doivent décrire une logique, pas un payload. Des exemples de condition générique incluent un processus parent du serveur web ou du pool FPM qui crée un interpréteur de shell ou un utilitaire de téléchargement, surtout après une rafale d’erreurs fatales mémoire ou de redémarrages de fils. Une autre famille corrèle une méthode POST avec des champs ou en-têtes multipart hors baseline de l’application et une réponse d’erreur en phase d’initialisation. Les seuils doivent naître du trafic légitime de l’environnement, car les vrais uploads et les imports lourds existent.

Côté WAF, Cloudflare a décrit des protections gérées pour php2shell activées le 21 octobre 2026 à 03:02 UTC. Elles ont couvert les plans Free et payants avec WAF. Le billet parle d’un ensemble de règles d’exécution anormale et d’une détection de transaction complète, qui combine signaux de requête et de réponse dans la même transaction HTTP. Cela réduit les faux positifs et bloque une réponse d’origine suspecte. C’est de la défense en profondeur. Cloudflare elle-même et php.net répètent que seul le correctif ferme le problème. Des attaquants tentaient déjà de muter le trafic contre les règles.

Une détection sans inventaire devient du théâtre. La règle Sigma ou le WAF que je garderais actifs demain sont ceux qui alertent sur un processus fils anormal et une panne d’initialisation liée au php2shell, pendant que le ticket de correctif des versions corrigées monte avec un propriétaire et un délai. Un WAF seul ne devient pas une acceptation de risque permanente.

Que faire en réponse à incident et pour la remédiation du php2shell

La remédiation complète du php2shell consiste à passer à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou à appliquer le paquet équivalent du fournisseur LTS et à redémarrer tous les workers. Si la ligne est 8.1 ou plus ancienne, le projet PHP n’émet pas de release normale. Il existe des backports minimaux de source pour 7.4, 8.0 et 8.1. L’orientation croisée de la CISA, du NCSC et du Centre canadien est d’isoler ou de retirer de l’exposition les systèmes qui ne peuvent pas monter jusqu’à une ligne corrigée. Les mitigations de configuration de l’avis officiel réduisent des chemins précis. Elles ne remplacent pas le binaire corrigé.

En réponse à incident, traitez toute preuve de shell sous le worker comme une compromission jusqu’à preuve du contraire. Isolez l’hôte ou le pool. Préservez les journaux d’accès, l’error_log PHP, le journal du service et la télémétrie de processus. Lancez une chasse aux webshells et à la persistance. Faites tourner les identifiants qui pouvaient être en mémoire du worker. Validez le niveau de correctif sur toute la flotte, pas seulement sur l’hôte symptomatique. Un effet collatéral du correctif peut inclure un changement de comportement OOM et de chemins de session. Testez en homologation lorsque le calendrier le permet. N’utilisez pas cela comme excuse pour garder un système exposé à Internet vulnérable au php2shell.

Après le correctif, ce qui reste souvent, c’est une appliance oubliée et une image de conteneur épinglée. Je ne clôturerais l’incident qu’avec un inventaire refait du php2shell, et avec la confirmation qu’aucun vieux worker ne tourne encore derrière le répartiteur.

Questions fréquentes sur php2shell

Cette section referme les doutes qui reviennent le plus dans les engagements red team et les war rooms du 21 octobre 2026 autour du CVE-2026-109618 et de l’ensemble php2shell. Les réponses ci-dessous séparent ce que l’avis officiel confirme de ce qui dépend encore de télémétrie tierce. Elles renforcent aussi la limite éthique du test. Utilisez-les comme check-list orale avec le client ou avec le SOC, sans transformer la FAQ en PoC.

Le CVE-2026-109618 est-il la même chose que php2shell?

Pas à lui seul. Php2shell est le surnom du couple CVE-2026-109618 et CVE-2026-109619. Le premier couvre la corruption via OOM dans l’initialisation et le nettoyage de la requête. Le second couvre l’état global stale entre requêtes dans le même worker. En inventaire et en ticket de correctif, traitez les deux ensemble. En hunting et en modèle de menace, conservez la différence de précondition, car les capteurs et la mitigation partielle ne sont pas identiques pour le php2shell.

L’authentification de l’application bloque-t-elle l’exploitation?

Sur les rameaux où le déclenchement survient avant le code de l’application, non. L’avis de php.net et les reproductions de laboratoire insistent sur des requêtes non authentifiées qui atteignent le moteur. Les contrôles de connexion du CMS ne sont pas le bon contrôle pour cette classe. C’est pourquoi le constat doit être classé comme exposition de runtime du php2shell, et non comme faille de plugin ou de formulaire authentifié.

Peut-on se fier uniquement au WAF en attendant le correctif?

Pas comme solution complète. Un WAF géré, comme celui décrit par Cloudflare, peut réduire l’exposition et gagner du temps. Il reste pourtant un risque de contournement et de faux négatif lorsque le parseur de bordure ne voit pas la même chose que PHP. L’isolement des systèmes exposés demeure l’alternative lorsque le correctif tarde. Une acceptation permanente de risque avec seulement un WAF est une décision fragile face à une RCE PHP sans authentification dans le php2shell.

PHP 7.x et 8.1 sont-ils corrigés par le projet?

Le projet n’entretient pas de releases normales pour ces lignes. Il a publié des backports minimaux de source pour 7.4, 8.0 et 8.1 et oriente vers les paquets des distributions et des vendors LTS. Sans paquet corrigé confirmé, l’orientation de plusieurs autorités est de migrer ou d’isoler. En pentest autorisé, enregistrez la ligne EOL comme exposition critique au php2shell jusqu’à preuve d’un backport appliqué et de workers redémarrés.

Existe-t-il déjà une exploitation de masse confirmée par toutes les autorités?

Il n’y a pas de consensus unique au 21 octobre 2026. La CISA a rapporté l’absence d’exploitation observée dans son alerte. Cloudflare, watchTowr et d’autres entreprises ont rapporté des tentatives ou du trafic d’attaque. Le Centre canadien a parlé d’une PoC disponible sans exploitation active identifiée à cette date. Traitez la divergence avec transparence et priorisez le correctif ainsi que la surveillance des processus liés au php2shell.

Comment prouver l’exposition sans exploiter?

Comparez version et paquet avec les releases corrigées, confirmez la SAPI et l’exposition réseau, puis documentez. Dans un laboratoire propre ou dans l’environnement autorisé par le RoE, la preuve de concept reste isolée. Sur une cible tierce sans autorisation formelle, tout déclenchement est illégal et hors périmètre éthique. La preuve acceptable dans un rapport est en général paquet plus configuration plus cartographie de surface du php2shell, et non un crash induit en production.

Conclusion

Le CVE-2026-109618 et le CVE-2026-109619 déplacent la discussion du bug de plugin vers la faille de runtime. L’impact est un shell sous l’utilisateur du serveur web. Pour le red team et pour la détection, la lecture utile du php2shell consiste à inventorier la SAPI et le niveau de correctif, puis à corréler les erreurs d’initialisation avec des processus fils anormaux. Les mitigations de configuration entrent comme réducteur de chemin, jamais comme fermeture du risque.

La majorité des environnements gagne davantage avec une flotte corrigée aux versions 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou avec un équivalent LTS vérifié, qu’avec un débat sur quel laboratoire a vu le premier exploit du php2shell. La réponse change lorsque PHP est embarqué dans une appliance sans canal de mise à jour. Là, le premier pas devient l’isolement et la pression sur le fournisseur. La chasse à la compromission doit assumer que la fenêtre après le 21 octobre 2026 a déjà été hostile.

Ce texte a un caractère informatif et éducatif sur le php2shell et les identifiants CVE-2026-109618 et CVE-2026-109619. Il ne remplace pas l’évaluation de votre fournisseur, de votre équipe de sécurité ou du responsable de l’environnement. Les tests techniques ne doivent avoir lieu que sur des infrastructures propres ou avec une autorisation formelle écrite du titulaire du système.