Aller au contenu
ProgrammationDécryptage

PHP2Shell : les deux failles critiques de PHP expliquées

PHP2Shell désigne deux failles de PHP notées 9.2 qui peuvent permettre à une seule requête de prendre le contrôle d'un serveur web. Leur fonctionnement, qui est exposé et ce qui les corrige entièrement.

Par

6 min de lecture

XLinkedIn

Traduit automatiquement de l'original anglais, vérifié et édité par Claire Whitmore. La version anglaise fait foi. Notre méthode

PHP's GitHub security advisory GHSA-w8hw-w9fx-j79w, titled RCE via OOM corruption and marked Critical, listing patched versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

En chiffres

CVSS v4.0 score PHP gives each flaw
9.2
date CISA listed both flaws as exploited
Oct 26
internet-exposed hosts running PHP, per one Shodan search
1.9M+

PHP2Shell est le surnom de deux failles de sécurité dans PHP, le langage de programmation qui fait tourner WordPress, Drupal et de nombreux autres sites web. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et PHP les a corrigées toutes les deux le 21 octobre 2026. PHP attribue à chacune une note de 9.2 sur 10 et indique qu'un attaquant sans compte peut les exploiter via Internet.

L'enjeu est monté d'un cran le 26 octobre. Ce jour-là, l'agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté les deux failles à son catalogue de bugs dont l'exploitation est avérée, selon Tenable. Les agences civiles fédérales doivent les corriger d'ici le 29 octobre.

Ce qu'est PHP2Shell et qui l'a découvert

PHP2Shell est un seul nom pour deux bugs distincts. Les récits divergent sur l'origine de ce nom. L'Insikt Group de Recorded Future indique que Wiz Research a trouvé les failles et les a nommées, en collaboration avec l'entreprise de sécurité Calif et avec OpenAI. Tenable attribue le nom à une vidéo de la chaîne d'exploitation partagée par le chercheur Kirill Firsov, qui a crédité LCFR de Calif.io.

La PHP Foundation a crédité Calif, OpenAI et Wiz, entre autres. Calif et Wiz ont tous deux déclaré avoir utilisé des modèles d'IA dans leurs recherches. Selon Calif, le plus ancien chemin de code concerné remonte à PHP 5.4.0, rapporte Tenable.

Comment fonctionnent les deux failles

Les deux bugs se trouvent dans le code que PHP exécute au début et à la fin de chaque requête web. Ce code s'exécute avant que le code propre d'un site, comme une extension WordPress, ait la moindre chance d'agir.

Un serveur web garde un ensemble de processus PHP à longue durée de vie, appelés workers. Chaque worker répond à une requête, fait le ménage, puis prend la suivante. Cette réutilisation signifie que les restes d'une requête peuvent affecter la suivante.

CVELibellé de PHPCe qui ne va pas
CVE-2026-109618Corruption OOMPHP manque de mémoire pendant qu'il construit les données internes d'une requête. L'étape de nettoyage traite alors ces données à moitié construites comme valides.
CVE-2026-109619État global périméDes données d'une requête continuent de pointer vers une mémoire déjà libérée. La requête suivante sur le même worker peut les utiliser avant que PHP ne les réinitialise.

OOM signifie « out of memory », c'est-à-dire un manque de mémoire. Les deux failles relèvent de ce que les programmeurs appellent un bug use-after-free : le programme continue d'utiliser un morceau de mémoire après l'avoir rendu. Un attaquant qui contrôle ce qui atterrit dans cette mémoire peut orienter le programme.

Recorded Future indique que les bugs comprennent un use-after-free dans le code qui lit les données de progression de téléversement de session. Il s'agit d'une fonction de PHP qui suit les téléversements de fichiers. Elle existe dans PHP depuis la version 5.4.0 et elle est activée par défaut, rapporte Recorded Future en citant des données de VirusTotal. Un bug connexe fait fuiter de la mémoire du worker. Selon Wiz, cela peut exposer des mots de passe, des jetons de connexion, des clés d'API et des certificats issus des requêtes d'autres personnes.

Qui est exposé à PHP2Shell

PHP indique que toute installation qui sert des requêtes web peut être concernée. Il cite PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, qui sont les principales façons dont un serveur web exécute PHP. PHP considère mod_php, qui exécute PHP à l'intérieur même du serveur web Apache, comme le plus à risque. Dans ce cas, une seule requête sans connexion peut déclencher un exploit démontré avant l'exécution de tout code applicatif.

Une attaque ne fonctionne pas partout. Field Effect, une entreprise de sécurité, indique que la réussite dépend de la version de PHP, du système d'exploitation, du serveur web, des réglages des workers et de la disposition de la mémoire. Elle « ne semble pas fiable de manière universelle dans tous les environnements concernés », a écrit l'entreprise.

Des chercheurs ont tout de même démontré des prises de contrôle complètes d'applications populaires. Selon Tenable, Calif a confirmé l'exécution de code sans connexion sur des versions précises de WordPress, Drupal, Joomla et Magento. Trail of Bits a obtenu des shells, c'est-à-dire le contrôle du serveur en ligne de commande, sur MediaWiki, Symfony, Laravel et phpBB.

PHP se cache aussi dans des produits que l'on n'associe pas à PHP. Field Effect cite Palo Alto Networks, Citrix, F5, HPE, NetApp, QNAP et Trend Micro parmi les éditeurs dont des produits sont concernés. Help Net Security a rapporté le 22 octobre que, selon Palo Alto, toutes les versions de ses logiciels PAN-OS et Panorama sont concernées, sans version corrigée pour l'instant.

Tenable cite une recherche Shodan de Henk Poley qui trouve plus de 1,9 million d'hôtes exposés sur Internet faisant tourner PHP. Faire tourner PHP ne rend pas à lui seul un serveur vulnérable.

Ce qui a changé et quand

Date (2026)Événement
19 aoûtWiz trouve la première faille avec des outils de recherche assistés par IA
24 aoûtWiz signale les failles en privé à l'équipe de sécurité de PHP
21 septembrePHP accuse réception du signalement et commence les correctifs
17 octobreLes serveurs leurres d'Amazon enregistrent une tentative d'exploitation
20 octobrePHP annonce une version d'urgence pour le lendemain
21 octobreDes détails fuitent en ligne quelques heures avant que PHP publie 8.5.12, 8.4.27, 8.3.36 et 8.2.35
23 octobrePHP divulgue CVE-2026-115560, une faille distincte liée à la progression de téléversement
26 octobreTrail of Bits signale des exploits fonctionnels ; la CISA liste les deux failles comme exploitées

PHP avait prévu la version pour le 22 octobre, selon la PHP Foundation, et l'a avancée après la fuite. Nous avons couvert l'annonce préalable puis la version du 21 octobre au fil des événements. Amazon a indiqué plus tard que ses honeypots, des serveurs leurres conçus pour attirer les attaquants, avaient détecté une tentative quatre jours avant la divulgation. Amazon ne sait pas comment l'attaquant a obtenu les détails à l'avance.

Lors de la publication, la PHP Foundation a déclaré n'avoir « identifié aucun exploit fonctionnel » parmi le code qui circulait en ligne. Cela a changé en quelques jours. Tenable rapporte que les honeypots d'un chercheur tournant sous PHP 8.4.26 ont été exploités le 24 octobre. Trail of Bits disposait d'exploits fonctionnels contre PHP 8.2 à 8.5 au 26 octobre. Recorded Future avertit toutefois que « les informations disponibles n'établissent pas toute l'étendue des exploitations réussies ni des compromissions confirmées ».

La faille du 23 octobre est un problème distinct que les versions du 21 octobre ne corrigent pas. PHP la décrit comme « un vecteur improbable d'exécution de code à distance dans la progression de téléversement de session ». Selon Field Effect, elle touche les applications qui modifient session.serialize_handler pendant l'exécution du programme, avant d'appeler session_start(), avec la progression de téléversement activée.

Ce que cela signifie pour les développeurs

La mise à jour est le seul correctif complet. Tout le reste ne fait que gagner du temps.

  • Mettez à jour, puis redémarrez chaque worker. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tenable note qu'un nouveau paquet ne corrige pas les processus déjà en cours d'exécution. Calif indique que l'ancien code reste en mémoire jusqu'à un redémarrage.
  • Sauvegardez d'abord la mémoire si un serveur a été sondé. Les recommandations de Google Cloud, rédigées avec Mandiant, conseillent de capturer la mémoire des workers avant de redémarrer. Un redémarrage efface les preuves.
  • Considérez les changements de réglages comme une solution provisoire. Le correctif provisoire de PHP pour la première faille est memory_limit=-1, défini de sorte que les applications ne puissent pas le remplacer. Pour la seconde, c'est session.upload_progress.enabled=0, plus fatal_error_backtraces=0 sur PHP 8.5.
  • Vérifiez le code de session pour CVE-2026-115560. Si une application modifie session.serialize_handler avant session_start(), désactivez la progression de téléversement jusqu'à la prochaine version régulière de PHP.
  • Surveillez les plantages de SimpleXML. Tenable signale une régression, le ticket php-src #24488, dans 8.4.27 et 8.5.12, qui peut faire planter certaines applications SimpleXML. Un correctif a été fusionné mais n'était pas encore publié au 26 octobre.
  • Regardez au-delà de vos propres serveurs. Les pare-feu, les baies de stockage et les outils de sécurité peuvent embarquer PHP, alors lisez l'avis de chaque éditeur. Examinez les journaux en remontant jusqu'au 17 octobre.
  • Planifiez la mise à niveau des versions PHP 7.4 à 8.1. Ces branches ne reçoivent que des correctifs source minimaux, sans version officielle. Demandez un rétroportage à votre distribution ou à votre éditeur de support.

Sources

  1. PHP2Shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities - Tenable
  2. PHP2Shell Exploitation: Two Critical PHP Flaws Explained - Recorded Future
  3. PHP2Shell: Critical PHP vulnerabilities patched, update now! - Help Net Security
  4. Another PHP issue identified while vendors report affected products - Field Effect

Articles liés