php2shell : deux RCE critiques dans le cœur de PHP

Le 21 octobre 2026 à 14:00 UTC (1), le projet PHP publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités critiques permettant une exécution de code à distance, abrégée RCE (2), par un attaquant non authentifié. La communauté les a réunies sous le nom php2shell avant même la publication. Les deux failles sont notées 9,2 sur l’échelle CVSS (3) version 4.0, sévérité critique.

La CVE (4) CVE-2026-109618, suivie par le projet sous l’identifiant GHSA (5) GHSA-w8hw-w9fx-j79w, tient à la gestion des dépassements de mémoire, abrégés OOM (6). La CVE-2026-109619, suivie sous GHSA-6wmf-4rv5-p3rp, tient à un état global périmé : des données internes propres à une requête survivent à la libération de leur mémoire et sont réutilisées lors d’une requête suivante. Les deux se situent dans des parties du moteur que presque toute requête traverse, ce qui explique à la fois leur gravité et la difficulté de les corriger sans casser la compatibilité ni dégrader les performances.

Sont exposées toutes les installations servant des requêtes web : PHP-FPM (7), Apache avec le module mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP estime le risque le plus élevé pour mod_php, où une requête non authentifiée peut déclencher l’attaque avant l’exécution du moindre code applicatif. La NSA (8) souligne que les failles résident dans PHP lui-même, et non dans l’application hébergée ni dans sa configuration : un serveur exécutant une version affectée est exploitable.

L’agence américaine CISA (9) et la NSA publient le 21 octobre une alerte et un avis appelant à corriger immédiatement. Le CERT-FR (10) publie le même jour l’alerte CERTFR-2026-ALE-014, mise à jour le 22 octobre, et l’avis CERTFR-2026-AVI-1359. L’alerte de la CISA recense celles des centres nationaux britannique, australien, néerlandais, néo-zélandais et canadien ; l’avis de la NSA renvoie en outre au CERT-EU (11).

Fig. 1. Chronologie reconstituée à partir du billet de la PHP Foundation, des archives de php.net, des fiches CVE, des alertes de la CISA et du CERT-FR, de l’avis de la NSA et de la FAQ de watchTowr.

Le délai entre l’identification du problème OOM en 2024 et sa correction est présenté par la PHP Foundation comme une défaillance structurelle. En 2024, aucun chemin vers une exécution de code n’était connu, et l’équipe de sécurité, réduite et fonctionnant au consensus, n’a pas tranché entre plusieurs correctifs aux inconvénients opposés : ruptures de compatibilité, risque de déni de service, ou modifications à coordonner sur de nombreuses extensions tierces. Le correctif est devenu la priorité de l’équipe à partir du 11 août 2026, quand plusieurs rapports ont établi la portée réelle du problème. La Foundation indique avoir décidé depuis de trancher les décisions de sécurité à la majorité.

Crédits

Les fiches CVE publiées par le PHP Group créditent Ryan, de Calif, et Wiz comme rapporteurs des deux vulnérabilités ; OpenAI y figure comme rapporteur de la CVE-2026-109619 et comme découvreur de la CVE-2026-109618. Le correctif est attribué à Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka et Nora Dossche. La PHP Foundation précise que les outils d’analyse assistée par l’IA, dont ceux d’OpenAI et d’Anthropic mis à sa disposition, servent à valider les rapports et à regrouper ceux qui partagent une cause racine, chaque décision et chaque correctif restant l’œuvre d’un développeur.

Pour les branches maintenues, toutes les sources concordent : chaque branche reçoit une version correctrice unique, qui couvre les deux CVE. Pour les branches hors support, trois lectures coexistent. Les fiches CVE du CNA ne listent que quatre plages affectées, de 8.2 à 8.5, avec un statut par défaut « unaffected » pour toute version non listée. L’alerte du CERT-FR liste comme affectées toutes les versions 5.x, 7.x, 8.0.x et 8.1.x. Le projet PHP, enfin, a publié pour 7.4, 8.0 et 8.1 des reports de correctif, ce qui revient à les traiter comme vulnérables, sans les faire figurer dans ses fiches.

Fig. 2. Versions concernées selon les fiches CVE-2026-109618 et CVE-2026-109619 publiées par le PHP Group, l’alerte CERTFR-2026-ALE-014 dans sa version du 22 octobre 2026 et l’avis de sécurité de php.net. Numéros de version comparés caractère par caractère entre ces sources et les deux avis GHSA.

Le CERT-FR rappelle que l’éditeur n’assure plus le support des branches 5.x, 7.x, 8.0.x et 8.1.x. watchTowr, dans sa FAQ mise à jour le 23 octobre, indique avoir confirmé que les branches anciennes non maintenues, dont PHP 5, sont affectées, et classe 7.3 et antérieures comme sans correctif disponible. Les reports source fournis par le projet pour 7.4, 8.0 et 8.1 s’adressent à ceux qui compilent eux-mêmes ou n’ont pas de fournisseur de support long terme ; ce ne sont pas des versions publiées.

Les fiches portent en outre deux conteneurs de données tiers : un conteneur ADP (14) de la CISA et un conteneur SADP (15) de Siemens, mécanisme par lequel un fournisseur publie des informations propres à ses produits. Le contenu de ces conteneurs n’apparaît pas dans la version consultée des fiches.

Distributions, conteneurs et vérification de version

Les distributions Linux et les fournisseurs de support long terme ont reçu les correctifs à l’avance. Une installation qui suit les paquets de sa distribution peut afficher un numéro de version inchangé, le correctif étant reporté dans la version empaquetée sans montée de version amont ; la vérification se fait alors sur le journal des modifications du paquet. Le contrôle porte sur le moteur qui sert réellement les requêtes, PHP-FPM ou mod_php, dont la version peut différer de celle de l’interpréteur en ligne de commande. Après mise à jour, tous les workers doivent être redémarrés pour que le correctif prenne effet.

PHP est souvent embarqué dans d’autres logiciels, et sa présence n’est pas toujours directement visible : la CISA et le CERT-FR demandent d’étendre l’inventaire aux produits, équipements et conteneurs qui intègrent un composant PHP, au-delà des serveurs web identifiés comme tels.

PHP utilise l’appel longjmp() pour interrompre le traitement d’une requête lorsqu’elle dépasse la limite mémoire memory_limit et sortir du contexte en cours. Dans certains contextes, la mémoire d’une requête est brièvement accessible avant d’être entièrement initialisée. Si une allocation échoue à cet instant, PHP ne tient pas compte de la sortie anticipée et laisse la mémoire de la requête dans un état invalide. L’allocation qui échoue n’a pas besoin d’être liée à la zone invalide. La procédure d’arrêt de la requête lit ensuite cet état ou y branche son exécution ; plusieurs stratégies d’OOM déclenchent cette condition de façon reproductible et mènent à une exécution de code.

Atteindre l’OOM en restant dans les limites apparentes

L’attaquant provoque le dépassement de mémoire à volonté. L’avis GHSA-w8hw-w9fx-j79w décrit plusieurs défauts d’analyse des requêtes multipart qui permettent d’y parvenir tout en respectant les limites affichées de PHP :

• une requête multipart sans longueur de contenu déclarée utilisable passe le contrôle initial de post_max_size et continue à fournir des données de corps décodées
• une partie multipart peut porter un nombre non borné d’en-têtes, dont la représentation en mémoire par PHP consomme bien plus que leur représentation sur le réseau, ce qui épuise memory_limit en restant sous post_max_size
• les champs de fichier vides ne comptent pas dans max_file_uploads mais créent les tableaux de métadonnées habituels, et des noms de champs imbriqués multiplient le travail d’allocation

L’OOM peut aussi être atteint par des chemins propres à l’application, chaque fois qu’une entrée contrôlée par l’attaquant provoque une allocation suffisamment grande ou un usage mémoire répété.

Le correctif

Le correctif retire l’appel longjmp() de la gestion de l’OOM et le remplace par deux mécanismes : un OOM souple, différé, déclenché au prochain point sûr de la machine virtuelle de PHP, et un OOM dur, immédiat, qui appelle _exit() si la consommation mémoire atteint un second seuil plus élevé. La procédure d’arrêt ne voit plus d’état invalide, et la capacité de PHP à limiter la consommation mémoire est conservée. La vulnérabilité est répertoriée sous les faiblesses CWE (16) 416 (utilisation après libération), 755 (gestion incorrecte de conditions exceptionnelles), 824 (accès à un pointeur non initialisé), 1325 (allocation séquentielle mal contrôlée) et 1419 (initialisation incorrecte de ressource).

L’impact confirmé est une exécution de code à distance non authentifiée avec les droits du compte du worker web. L’exécution de code complète a été validée contre mod_php avec les limites mémoire et d’entrée par défaut et une configuration prefork ordinaire à plusieurs workers. Des workers supplémentaires et un trafic sans rapport augmentent le nombre de tentatives nécessaires sans supprimer la condition ; la portabilité et la fiabilité de l’exploit dépendent de la compilation de PHP, des extensions, du comportement du frontal et de l’agencement de l’allocateur.

PHP conserve dans chaque worker divers états globaux : état d’erreur, de session, d’objet ou d’extension. Ces états pointent vers de la mémoire appartenant à une seule requête et doivent être réinitialisés avant la libération de cette mémoire. Certaines opérations d’entrée, de configuration, de session et de gestion d’erreur s’exécutent avant l’initialisation normale de la requête suivante. Elles accèdent alors à un état périmé que la requête précédente n’a pas réinitialisé, ce qui produit une utilisation après libération ; un agencement du tas, la zone de mémoire allouée dynamiquement, préparé par l’attaquant donne une exécution de code.

Producteur et consommateur

L’exploitation suppose deux opérations distinctes. Le producteur est une opération PHP qui stocke un état propre à une requête dans un emplacement accessible plus tard. Le consommateur est une opération d’une requête suivante qui lit cet état périmé, le libère ou y branche son exécution, avant que l’initialisation normale ne le réinitialise. Les deux surviennent dans des requêtes HTTP (17) différentes traitées par le même worker.

L’état peut survivre pour deux raisons. Une erreur fatale, y compris une erreur due à l’épuisement mémoire, abandonne une opération avant la réinitialisation correspondante. Un avertissement ou un autre message non fatal peut aussi repeupler l’état d’erreur après qu’il a été vidé lors de l’arrêt.

Fig. 3. Cas de producteur et de consommateur décrits par l’avis GHSA-6wmf-4rv5-p3rp. Session upload progress est activée par défaut et ne requiert aucun appel applicatif à session_start().

Pour le cycle de session upload progress, le déclencheur indépendant de l’application est un OOM pendant le traitement de l’entrée. Avec mod_php, producteur et erreur fatale peuvent survenir pendant le démarrage multipart ; la variante FPM validée publie l’état pendant l’exécution applicative, atteint une erreur fatale, puis utilise session upload progress comme consommateur précoce, ce qui suppose une opération applicative adaptée. Pour les diagnostics de configuration, l’avis cite notamment des réglages obsolètes comme auto_detect_line_endings=1, des réglages mbstring ou iconv explicitement définis, des valeurs malformées de memory_limit et des chemins rejetés par open_basedir. Avec mod_php, la configuration de répertoire et les fichiers .htaccess sont appliqués avant l’initialisation de la requête ; avec FPM, l’exposition est conditionnelle aux paramètres PHP_VALUE et PHP_ADMIN_VALUE transmis par le frontal.

L’impact confirmé est une utilisation après libération non authentifiée, une divulgation mémoire et une exécution de code à distance avec les droits du worker web. Les faiblesses retenues sont les mêmes que pour la CVE-2026-109618 : CWE-416, 755, 824, 1325 et 1419.

Le mode d’exécution de PHP détermine le niveau de risque, parce qu’il décide si la procédure d’arrêt de la requête est appelée même quand le démarrage a échoué.

Fig. 4. Exposition par mode d’exécution, selon les deux avis GHSA. « Validé » signifie exploit complet démontré ; « jugé exposé » relève de l’analyse de code sans exploit complet.

Apache mod_php appelle la procédure d’arrêt de la requête sans condition, même quand le démarrage a échoué. Pendant ce démarrage, l’analyse automatique du corps peut épuiser la limite mémoire et sortir de la requête dans un contexte où l’état est temporairement invalide, que l’arrêt traite ensuite, avant le moindre code applicatif. PHP-FPM termine au contraire le processus enfant quand le démarrage échoue, ce qui bloque ce chemin précis et retire le processus du pool ; l’analyse de code le juge néanmoins exposé par d’autres voies, et la CVE-2026-109619 y a été exploitée avec succès.

Les deux avis GHSA insistent sur un point : seule la mise à jour est une protection complète. Les mesures ci-dessous réduisent l’exposition à des chemins d’attaque précis sans rendre une installation sûre. Elles se posent dans une configuration appliquée avant l’analyse de la requête, php.ini, pool FPM ou configuration du serveur, jamais par ini_set() ni par un fichier .user.ini de FPM. Chaque changement suppose le redémarrage de tous les workers.

Contre la corruption par OOM (CVE-2026-109618)

• fixer memory_limit=-1, de préférence sans que les applications puissent la redéfinir, par exemple avec php_admin_value dans le pool FPM ou la configuration Apache, et vérifier qu’aucun pool, répertoire ou réglage applicatif ne rétablit une limite finie. Cela retire l’échec de limite mémoire contrôlable, mais un échec d’allocation sous-jacent, par exemple de mmap(), peut encore atteindre le chemin vulnérable
• garder post_max_size bas, 8 Mo sans envoi de fichiers et 32 Mo avec, maintenir upload_max_filesize sous post_max_size, réduire max_input_nesting_level, et faire appliquer en amont, au serveur web ou au proxy, des limites sur la taille décodée, le nombre de champs, de parties multipart, d’en-têtes par partie et de téléversements, y compris pour les requêtes sans longueur de contenu utilisable ; bloquer les requêtes multipart avant PHP si l’application ne les utilise pas
• utiliser une limite mémoire de conteneur ou de cgroup comme borne de disponibilité, de préférence avec une politique qui ne tue que le worker affecté. Ne pas substituer RLIMIT_AS ni RLIMIT_DATA, qui font échouer mmap() et déclenchent précisément le chemin vulnérable

Contre l’état global périmé (CVE-2026-109619)

• fixer session.upload_progress.enabled=0 et redémarrer tous les workers : bloque les chemins de session confirmés, pas les autres variantes, et ne fait rien pour la CVE-2026-109618
• sur PHP 8.5, fixer fatal_error_backtraces=0 et redémarrer tous les workers : bloque le seul chemin confirmé de la trace d’erreur fatale
• retirer les réglages invalides ou obsolètes appliqués par requête qui émettent un diagnostic avant l’initialisation ; masquer les diagnostics par error_reporting, display_errors ou l’opérateur @ ne protège pas
• corriger les erreurs fatales et les dépassements de délai atteignables par un attaquant, y compris dans les rappels, le traitement des téléversements ou des imports, les destructeurs et le nettoyage ; à défaut de contrainte de performance, limiter chaque worker à une requête avec pm.max_requests=1

Les trois autorités dont les publications ont été consultées convergent sur la mise à jour immédiate et sur la mise hors ligne ou l’isolement des systèmes qui ne peuvent pas être corrigés. Elles se distinguent par les mesures d’accompagnement.

Fig. 5. Recommandations de la CISA, de la NSA et du CERT-FR, d’après leurs publications des 21 au 23 octobre 2026.

Le blocage des requêtes multipart recommandé par le CERT-FR va au-delà de la mesure du projet, qui le réserve aux applications n’utilisant pas ce type de requête : il interrompt tout téléversement de fichier. Il couvre les stratégies d’OOM par analyse multipart de la CVE-2026-109618 et le chemin session upload progress de la CVE-2026-109619, qui repose sur un téléversement. Il ne couvre ni le chemin de la trace d’erreur fatale sur PHP 8.5, ni les chemins propres à l’application. Le paramètre php_admin_flag mentionné par le CERT-FR répond à la même exigence que celle des avis GHSA : poser le réglage à un niveau que l’application ne peut pas redéfinir et qui s’applique avant l’analyse de la requête.

La divulgation coordonnée a déraillé deux jours avant la date de release prévue. Le 20 octobre 2026, les deux identifiants CVE ont circulé avec une heure de release et un score erronés, sans détail technique. Le projet a avancé sa pré-annonce et déplacé la release du 22 au 21 octobre, compromis entre la rapidité et le temps laissé aux distributions pour empaqueter le correctif. La vidéo de démonstration publiée par erreur par Calif a révélé quelques détails supplémentaires et, selon la PHP Foundation, accéléré le développement de PoC. Le conseil de mitigation transmis à quelques fournisseurs d’infrastructures critiques vers 23:00 UTC le 20 octobre a pu fuiter également. Le 21 octobre à 07:41 UTC, Chainguard a publié des images contenant le correctif, exposant celui-ci sous forme binaire à l’analyse plus de six heures avant que les autres utilisateurs ne disposent de la mise à jour.

Les constats sur l’exploitation diffèrent selon les sources, et sont à tenir séparés :

• la PHP Foundation indique avoir inspecté les PoC apparus après la fuite sans identifier d’exploit fonctionnel au moment de la divulgation
• la CISA écrit le 21 octobre ne pas avoir observé d’exploitation réussie
• le CERT-FR indique le 22 octobre avoir connaissance de PoC pour des déploiements spécifiques de PHP
• watchTowr indique observer une exploitation en conditions réelles depuis le 21 octobre dans son réseau de honeypots, et maintient ce constat dans sa FAQ mise à jour le 23 octobre
• au 25 octobre 2026, aucune des deux CVE ne figure au catalogue KEV (20) de la CISA, constat déjà fait par watchTowr au 22 octobre ; l’alerte de la CISA mise à jour le 23 octobre ne mentionne pas d’inscription
• aucune attribution à un acteur n’a été rendue publique

L’exploitation se manifeste typiquement par des processus enfants anormaux lancés directement par les processus de travail de PHP, par exemple un interpréteur de commandes issu de php-fpm, php-cgi, httpd ou apache2. La CISA recommande de surveiller les workers PHP qui lancent des shells ou téléchargent des outils, et met à disposition une règle Sigma dans son dépôt GitHub, qu’elle annonce susceptible d’évoluer. Le CERT-FR conseille de superviser les requêtes multipart lorsqu’elles ne peuvent pas être bloquées.

Un audit de configuration et de journalisation complète la détection. Activer log_errors=On, un error_log fonctionnel et error_reporting=E_ALL dans la configuration de démarrage, le temps d’une revue isolée, permet de repérer dans les journaux d’Apache, de PHP-FPM, du proxy et des services :

• les avertissements, dépréciations et erreurs cœur répétés avant l’exécution des scripts cibles
• les diagnostics produits pendant le nettoyage d’extension ou de serveur
• les erreurs fatales, d’analyse et non capturées, et les messages Maximum execution time exceeded
• les échecs limités à des routes, des types de contenu, des fichiers ou des options contrôlés par un attaquant

L’absence d’erreur dans les journaux ne prouve pas l’absence de vulnérabilité : les journaux historiques ont pu exclure les dépréciations, une revue même exhaustive ne couvre que les chemins effectivement exercés, et un échec peut survenir avant l’écriture du message. En cas de compromission suspectée d’un serveur exposé, le CERT-FR renvoie à sa fiche réflexe d’endiguement d’un équipement de bordure, CERTFR-2025-RFX-002.

Les deux avis GHSA, les fiches CVE, l’avis de sécurité et les archives de php.net, le billet de la PHP Foundation, les publications de la CISA, de la NSA et du CERT-FR sont des sources primaires, lues en intégralité. La FAQ de watchTowr est une source d’éditeur. Les versions et le vecteur CVSS ont été recoupés entre ces sources.

1. UTC (1) : Coordinated Universal Time, temps universel coordonné.
2. RCE (2) : Remote Code Execution, exécution de code à distance.
3. CVSS (3) : Common Vulnerability Scoring System, système de notation de la gravité des vulnérabilités.
4. CVE (4) : Common Vulnerabilities and Exposures, identifiant public attribué à une vulnérabilité.
5. GHSA (5) : GitHub Security Advisory, identifiant d’avis de sécurité attribué par GitHub.
6. OOM (6) : Out Of Memory, dépassement de la mémoire disponible ou autorisée.
7. PHP-FPM (7) : PHP FastCGI Process Manager, gestionnaire de processus FastCGI de PHP.
8. NSA (8) : National Security Agency, agence américaine chargée du renseignement d’origine électromagnétique et de la cybersécurité des systèmes nationaux.
9. CISA (9) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
10. CERT-FR (10) : centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques, rattaché à l’Agence nationale de la sécurité des systèmes d’information.
11. CERT-EU (11) : service de cybersécurité des institutions, organes et agences de l’Union européenne.
12. CNA (12) : CVE Numbering Authority, organisme habilité à attribuer des CVE et à publier leur fiche ; ici le PHP Group.
13. PoC (13) : Proof of Concept, code démontrant la faisabilité d’une exploitation.
14. ADP (14) : Authorized Data Publisher, organisme autorisé à enrichir une fiche CVE de données complémentaires.
15. SADP (15) : Supplier Authorized Data Publisher, fournisseur autorisé à publier dans une fiche CVE des informations propres à ses produits.
16. CWE (16) : Common Weakness Enumeration, classification des faiblesses logicielles.
17. HTTP (17) : Hypertext Transfer Protocol, protocole de transfert du web.
18. LSAPI (18) : LiteSpeed Server Application Programming Interface, interface d’exécution de PHP sous LiteSpeed.
19. WAF (19) : Web Application Firewall, pare-feu applicatif.
20. KEV (20) : Known Exploited Vulnerabilities, catalogue de la CISA des vulnérabilités dont l’exploitation est constatée.
21. LLM (21) : Large Language Model, grand modèle de langage.

1. PHP, Security advisory: Critical remote code execution vulnerabilities, update now, 21 octobre 2026. php.net/archive/2026
2. PHP (GitHub php-src), RCE via OOM corruption, avis GHSA-w8hw-w9fx-j79w, 21 octobre 2026. github.com/php/php-src
3. PHP (GitHub php-src), RCE via stale global state, avis GHSA-6wmf-4rv5-p3rp, 21 octobre 2026. github.com/php/php-src
4. CVE Program, fiche CVE-2026-109618, CNA PHP Group, publiée le 21 octobre 2026. cve.org
5. CVE Program, fiche CVE-2026-109619, CNA PHP Group, publiée le 21 octobre 2026. cve.org
6. The PHP Foundation, Today’s PHP Security Release, and How We’re Strengthening PHP Security, 21 octobre 2026. thephp.foundation
7. CISA, Critical Vulnerabilities in PHP Require Immediate Patching, 21 octobre 2026, mise à jour le 23 octobre 2026. cisa.gov
8. NSA, NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities, 21 octobre 2026. nsa.gov
9. CERT-FR, [Màj] Multiples vulnérabilités dans PHP, alerte CERTFR-2026-ALE-014, 21 octobre 2026, mise à jour le 22 octobre 2026. cert.cyber.gouv.fr
10. watchTowr, Frequently Asked Questions About PHP Remote Code Execution (PHP2Shell CVE-2026-109618 & CVE-2026-109619), 20 octobre 2026, mise à jour le 23 octobre 2026. watchtowr.com
11. PHP, Informational advisory: Session upload progress, 23 octobre 2026. php.net/archive/2026
12. CISA, catalogue Known Exploited Vulnerabilities, consulté le 25 octobre 2026. cisa.gov/known-exploited-vulnerabilities-catalog