PHP2Shell

Deux exécutions de code à distance dans le moteur PHP

PHP2Shell désigne deux vulnérabilités du moteur PHP lui-même, et non d'une application écrite en PHP : CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, « RCE via OOM corruption ») et CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, « RCE via stale global state »). L'équipe PHP, qui est l'autorité de numérotation (CNA) de ces deux CVE, note chacune 9.2 en CVSS v4.0, vecteur AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. Toutes deux permettent une exécution de code à distance sans authentification et concernent, selon l'avis de sécurité du 21 octobre 2026, toutes les installations qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Les deux failles partagent une racine. Le registre CVE la décrit ainsi : PHP utilise longjmp() pour sortir du contexte courant lors d'un dépassement mémoire, et certains contextes laissent alors la mémoire de la requête non initialisée ; le nettoyage qui suit peut lire cette mémoire ou brancher dessus. Pour la seconde faille, un état global pointe temporairement dans la mémoire de la requête, n'est pas remis à zéro ou se repeuple après l'avoir été, et la requête suivante traitée par le même worker lit cet état périmé avant son initialisation. Le registre CVE classe les deux failles sous CWE-416 (use-after-free), CWE-755, CWE-824, CWE-1325 et CWE-1419 ; le NVD reprend les quatre premières, avec la mention « source : security@php.net ». Sansec les résume en « use-after-free ». Wiz décrit en plus une fuite de mémoire du worker : des fragments du tas renvoyés dans le cookie PHPSESSID, qui peuvent contenir des secrets d'autres requêtes.

PHP juge le risque le plus élevé sur mod_php, avec un exploit démontré où une requête non authentifiée déclenche l'attaque avant l'exécution de tout code applicatif. Sansec rapporte des exécutions de code non authentifiées confirmées sur Magento 2.4.9 et dix autres applications : WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 et WHMCS. Wiz a de son côté obtenu une exécution de code avant authentification sur les images Docker officielles wordpress:latest, drupal:latest et joomla:latest. Une application sans défaut reste donc exposée si l'interpréteur qui la sert l'est.

mod_php et PHP-FPM : ce que les avis démontrent

Les avis GitHub du projet PHP distinguent les deux failles selon la SAPI. Pour CVE-2026-109618, « complete remote code execution was validated over HTTP against mod_php ». L'analyse du code rend PHP-FPM « susceptible », mais « no complete FPM exploit has been demonstrated for this SAPI » : FPM termine le processus enfant quand le démarrage de la requête échoue, alors que mod_php et FrankenPHP appellent la procédure d'arrêt dans tous les cas. L'avis juge FrankenPHP « likely susceptible » et, pour LiteSpeed (LSAPI), des exploits dépendant de l'application « likely but unvalidated ».

Pour CVE-2026-109619, l'avis écrit : « Session lifecycle RCE was validated against mod_php and FPM ». Le chemin FPM fonctionne avec un pool dynamique ordinaire mais « depends on a suitable application operation » ; le chemin des backtraces d'erreurs fatales n'a d'exécution de code confirmée que sur mod_php, et l'avis en fait son cas démontré le plus solide. La PHP Foundation résume le 21 octobre : exécution de code complète démontrée sur Apache avec mod_php en configuration par défaut pour la faille OOM, et confirmée aussi sur PHP-FPM par des chemins applicatifs. Calif, qui écrit que « the available exploitation paths depend on the PHP version and SAPI », publie une vidéo de son exploit contre Nginx avec PHP-FPM. Une installation FPM se met donc à jour comme les autres.

Versions touchées et correctifs

Le 21 octobre 2026, le projet PHP publie 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux et les éditeurs LTS ont reçu les correctifs en avance. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet ; vu la gravité, l'équipe de sécurité a tout de même publié des backports minimaux en sources pour PHP 7.4, 8.0 et 8.1, sous forme de branches GitHub, pour ceux qui compilent eux-mêmes ou n'ont pas d'éditeur LTS. Le CERT-FR liste les branches 5.x à 8.1.x comme affectées, l'éditeur n'en assurant plus le support, sans mentionner ces backports.

Wiz écrit que presque chaque version de PHP est touchée par au moins une des deux failles, « including releases dating back to PHP 5.4 ». Calif date le chemin le plus ancien de PHP 5.4.0 et précise que son exécution de code contre des scripts PHP arbitraires sous Apache mod_php vaut pour PHP 7.3 et suivants. PHP a demandé aux utilisateurs du dépôt bénévole rpms.remirepo.net de passer aux paquets de leur distribution ou de compiler depuis les sources, le dépôt n'ayant pas de mise à jour le jour même. Un paquet corrigé sur disque ne protège pas tant que les anciens processus servent les requêtes : les mesures de PHP répètent « restart every worker ».

Chronologie

Les dates qui suivent viennent des chronologies publiées par Calif et Sansec, du blog de Wiz, des annonces php.net et du Discourse de la PHP Foundation, du billet de la PHP Foundation, du registre CVE et des avis du CERT-EU et du CERT-FR, tous datés du 21 octobre 2026. Les heures sont en UTC.

• 2024 : audit externe de PHP par Quarkslab, organisé par l'OSTIF et financé par la Sovereign Tech Agency (PHP Foundation). Calif indique que cet audit avait identifié un bug lié au rapport #78876, sans exploitation prouvée. Greg Brockman, président d'OpenAI, parle d'une version limitée du bug repérée en 2024 sans être jugée significative, et d'un défaut présent dans PHP depuis quatorze ans.
• 1er août 2026 : Calif identifie plusieurs chemins d'exécution de code dans PHP (chronologies de Calif et de Sansec).
• 11 août : Calif signale le premier bug à l'équipe PHP et ouvre la divulgation coordonnée. La PHP Foundation écrit qu'OpenAI a signalé indépendamment la même cause racine le même jour. Calif partage une preuve de concept le 14 août, que PHP confirme le 15, puis signale le second bug le 21 août.
• 19 août : Wiz Research découvre la première vulnérabilité ; exécution de code confirmée sur Drupal le 20 et sur WordPress le 21 ; Wiz transmet ses rapports à PHP le 24 août. PHP en accuse réception le 21 septembre.
• 18 septembre : OpenAI signale à PHP des vecteurs d'attaque supplémentaires (PHP Foundation). Greg Brockman écrit que son équipe a trouvé « a more complete version independently in September ».
• 20 octobre : vers 15h00, les identifiants CVE apparaissent en ligne avec une heure de publication erronée et un score erroné, 10.0 au lieu de 9.2 (PHP Foundation). Calif publie par erreur une vidéo de sa preuve de concept, dont des copies circulent. watchTowr confirme une exécution de code et publie sa FAQ à 19h35. PHP avance sa pré-annonce : Jakub Zelenka (bukka) la poste sur le Discourse de la PHP Foundation à 19h33, deux vulnérabilités notées CVSS v4.0 9.2, publication prévue le 21 octobre à 14h00, avec réserve de publier plus tôt en cas de fuite ou d'exploitation active.
• 21 octobre, 3h02 : les clients Cloudflare, offre gratuite comprise, sont protégés par défaut par des règles WAF, environ neuf heures avant la divulgation publique. À 7h41, Chainguard publie des images corrigées, plus de six heures avant la publication coordonnée, ce que la PHP Foundation qualifie de rupture d'embargo. À 7h43, Dane Knecht, CTO de Cloudflare, signale les premières attaques et rappelle que ces règles sont un palliatif en attendant le correctif.
• 21 octobre, de 13h30 à 14h03 : les versions corrigées sortent en avance sur l'horaire annoncé (13h30 selon le CERT-EU). Le registre CVE publie les deux fiches à 13h48 et 13h54, Calif met son analyse en ligne à 13h52, l'annonce de PHP 8.5.12 est postée sur le Discourse à 14h03 par Daniel Scherzer. Wiz, OpenAI, la PHP Foundation et Google Cloud publient leurs billets. Le CERT-FR émet l'alerte CERTFR-2026-ALE-014, le CERT-EU l'avis 2026-018, et l'ANSSI relaie sur X à 13h59 une mise à jour « dont l'exploitation rapide est à craindre ». Le NVD publie les deux fiches à 14h17.

Les mesures de contournement listées par PHP, et leurs limites

L'équipe PHP prévient que seule la mise à jour est une solution complète : les mesures ci-dessous « réduisent l'exposition à des chemins d'attaque précis mais ne rendent pas une installation sûre ». Chacune porte sa propre réserve dans l'avis d'origine.

• Contre CVE-2026-109618 : memory_limit=-1, imposé de façon qu'aucune application ne puisse le changer (php_admin_value dans le pool FPM ou la configuration Apache), en vérifiant qu'aucun réglage de pool, de répertoire ou d'application ne remet une limite finie. PHP précise qu'un échec d'allocation sous-jacent peut encore atteindre le chemin vulnérable.
• Un post_max_size bas : 8M sans téléversement de fichiers, 32M sinon, avec upload_max_filesize en dessous. PHP suggère aussi des limites au serveur web ou au proxy sur la taille décodée, le nombre de champs, de parts multipart et d'en-têtes, et la profondeur d'imbrication, limites qui doivent aussi couvrir les requêtes sans Content-Length utilisable.
• Une limite de conteneur ou de cgroup comme borne de disponibilité, de préférence avec une politique qui ne tue que le worker touché. Ne pas y substituer RLIMIT_AS ni RLIMIT_DATA, qui peuvent provoquer l'échec d'allocation vulnérable.
• Contre CVE-2026-109619 : session.upload_progress.enabled=0 puis redémarrage de chaque worker, via php.ini, le pool FPM ou la configuration serveur, jamais via ini_set() ni .user.ini. Cette mesure bloque les chemins de session confirmés, pas les autres variantes.
• Sur PHP 8.5, fatal_error_backtraces=0 puis redémarrage de chaque worker : ne bloque que le chemin confirmé des backtraces d'erreurs fatales.
• Supprimer les réglages invalides ou dépréciés appliqués par requête qui émettent des diagnostics avant l'initialisation (les masquer avec error_reporting, display_errors ou @ n'aide pas), et corriger les erreurs fatales et dépassements de délai qu'un attaquant peut atteindre, y compris dans les callbacks, le traitement des téléversements et le nettoyage.
• Le CERT-FR ajoute l'isolement des équipements affectés et le blocage, ou à défaut la supervision, des requêtes HTTP dont le Content-Type vaut multipart. Il précise que ces contournements provisoires ne sont pas qualifiés par ses services. Cloudflare présente ses règles WAF comme une couche de défense en profondeur et demande de corriger PHP malgré elles.
• Google Cloud publie le même jour un guide signé Chris Betz (CISO de Google Cloud) et Raluca Ada Popa (Google DeepMind) : passer à PHP 8.2 ou plus récent et redéployer ; les runtimes supportés d'App Engine standard sont corrigés automatiquement, Cloud Run et GKE demandent de reconstruire les images avec un PHP corrigé, et l'On-Demand Scanning API et Security Command Center servent à repérer les images vulnérables. Google Cloud indique que ses propres services ne sont pas vulnérables.

Qui a trouvé quoi, et avec quels outils

OpenAI écrit que Calif a identifié une faille critique avec GPT-5.6 Sol dans le cadre de son programme Patch the Planet, et que Wiz a découvert et signalé indépendamment les deux vulnérabilités. L'analyse de Calif est signée Ryan Austin. Wiz (Sagi Tzadik, Shir Tamari, Nir Ohfeld et Tomer Schwartz) indique avoir utilisé Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol tout au long de la recherche, crédite Gemini 4 Argon d'une contribution à la découverte, au développement de l'exploit, à la détection et à la validation du correctif, et résume : « a single researcher completed in a week what previously would have taken a world-class team months of work ». Son analyse détaille quatre bugs sous-jacents : un use-after-free dans le désérialiseur d'upload-progress, une divulgation de mémoire du processus à distance, un use-after-free dans les backtraces d'erreurs fatales et une confusion de types dans OPcache. Le site php2shell.com, édité par Wiz, crédite la recherche à Wiz Research, OpenAI Codex Security et Calif, la coordination à l'équipe sécurité PHP et à l'équipe Gemini de Google, et rassemble les billets des éditeurs partenaires.

Les crédits divergent sur un nom. Cloudflare écrit que « Calif.io, Wiz, OpenAI and Quarkslab » ont divulgué les deux vulnérabilités. Les fiches du registre CVE, rédigées par PHP, créditent « Ryan at Calif.io », Wiz et OpenAI ; la PHP Foundation situe Quarkslab dans l'audit externe de 2024, et Calif dans le bug lié repéré à cette occasion. Cette fiche retient les trois découvreurs crédités par PHP et signale la mention de Cloudflare sans la trancher.

OpenAI décrit une coalition menée pendant deux mois avec des mainteneurs, des chercheurs et des fournisseurs de sécurité, en lien avec la « Super Intelligence Force » de la Maison Blanche, l'Office of the National Cyber Director (ONCD), la CISA et des partenaires internationaux, et un cadre de réponse en cinq étapes : valider et corriger la faille en amont, laisser du temps aux organisations touchées, coordonner avec les gouvernements, préparer les mises à jour dans les produits, publier des guides une fois le correctif disponible. Le billet forge l'expression Defender's Window : « To our knowledge, frontier AI found these vulnerabilities before attackers did », ce qui a laissé aux mainteneurs et aux fournisseurs le temps de préparer correctifs et protections avant la divulgation. OpenAI publie un vérificateur de version, php2shell-checker, sur GitHub sous licence Apache 2.0 : un script Node.js qui déduit la version de PHP des en-têtes HTTP ou de php -v et répond OK, VULNERABLE ou UNKNOWN sans envoyer de requête d'exploitation. Il ouvre des abonnements « Codex for OSS » aux mainteneurs et rappelle son engagement d'un milliard de dollars d'accès Daybreak subventionné. OpenAI ajoute que ces bugs sont « among several significant vulnerabilities we've already found and are working to fix » et s'attend à ce que ce type de découvertes « increase sharply in the coming months ». Greg Brockman parle, dans un article publié sur X, d'une nouvelle phase de la cybersécurité où les modèles trouvent des vulnérabilités à l'échelle d'internet. Wiz situe pour sa part ces failles « among the most severe vulnerabilities discovered in PHP » ; c'est l'appréciation d'un des découvreurs.

La fenêtre se referme à la publication. Le même 21 octobre, Jake Knott, responsable du renseignement sur les menaces chez watchTowr, observait déjà des tentatives d'exploitation menées avec des preuves de concept « vibecoded with the help of AI ». La fiche recherche de vulnérabilités par IA replace l'épisode parmi les autres découvertes de 2026, et l'article PHP2Shell : l'IA a trouvé la faille avant les attaquants, la course au patch commence détaille ce que cela change pour les équipes qui exploitent du PHP.

État au 21 octobre 2026 en fin d'après-midi

Relevé le 21 octobre 2026 vers 16h30 UTC, deux heures et demie après la publication des correctifs ; ces éléments se périment vite. Aucune exploitation réussie n'était confirmée : Patchstack écrivait à 13h57 UTC que sa télémétrie ne montrait que des sondes, « with no hard evidence of breaches yet » ; la PHP Foundation indiquait qu'aucun exploit fonctionnel n'était connu au moment de la publication, hors les preuves de concept qui circulaient depuis la fuite ; Jake Knott (watchTowr) déclarait à The Record : « Whilst nobody has been successful to date, we don't expect that will last long. » La FAQ de watchTowr affiche pourtant « Exploitation: In The Wild » pour les deux CVE, avec la mention « Yes, per watchTowr » et « Exploitation has been observed in the wild as of the 21st of October » sur la base de son réseau de pots de miel, tout en indiquant « CISA KEV: Not listed ». Le catalogue KEV de la CISA, version 2026.10.21 publiée à 14h04 UTC (1 754 entrées), ne contenait ni CVE-2026-109618 ni CVE-2026-109619 au relevé de 16h31 UTC, et l'avis de PHP ne mentionne aucune exploitation. Les deux lectures coexistent : des tentatives observées côté watchTowr, aucune intrusion confirmée ni inscription au KEV côté PHP, Patchstack et CISA.

Sur le score, un chiffre erroné a circulé. La PHP Foundation écrit que les identifiants CVE sont apparus en ligne le 20 octobre vers 15h00 UTC « with a wrong CVSS score of 10.0 » ; le score attribué par PHP, repris par le registre CVE, le NVD et la FAQ de watchTowr, est 9.2 en CVSS v4.0. Le NVD a publié les deux fiches à 14h17 UTC, au statut « Undergoing Analysis », en reprenant le score et les CWE fournis par PHP. Aucune version corrective supplémentaire n'avait suivi.

Sansec s'attend à une exploitation de masse maintenant que le correctif et les analyses sont publics. The Record rapporte que des centaines de sites ont été mis hors ligne par précaution : plusieurs gouvernements ont coupé certains sites avant la sortie du correctif, de même que Nintendo et d'autres organisations.