PHP2Shell : 10 ans de sommeil, une semaine de chaos.

Il y a des semaines où l’on découvre que l’on surveillait le mauvais composant. Le 21 octobre 2026, à 14 h 00 UTC précises, l’équipe de développement de PHP a publié un correctif de sécurité. Dans l’heure qui a suivi, Cloudflare, Akamai, AWS, Fastly, Imperva, Microsoft, Vercel et Google avaient tous déployé des règles de filtrage temporaires, Cloudflare jusqu’à les activer pour ses clients de l’offre gratuite. Ce genre de synchronisation ne s’improvise pas. Elle se prépare pendant des jours, parfois des semaines, dans un silence que seule une poignée de personnes partage.
Ce que ces entreprises s’apprêtaient à colmater, c’est une paire de vulnérabilités dans le moteur de PHP lui-même. Pas dans WordPress. Pas dans un plugin acheté sur une place de marché. Dans l’interpréteur qui fait tourner à peu près 70 % du web.
Elles portent les références CVE-2026-109618 et CVE-2026-109619. Les chercheurs les ont surnommées PHP2Shell. Note CVSS v4.0 : 9,2.

Ce qui s’est passé, dans l’ordre

L’histoire commence en août 2026, quand Wiz Research, en collaboration avec Calif et OpenAI, met la main sur une famille de défauts présents dans le code de PHP depuis plus d’une décennie. La découverte doit beaucoup à des modèles d’IA frontière : nous y reviendrons, parce que c’est peut-être l’enseignement le plus important de toute l’affaire.

Le 20 octobre, les identifiants CVE et une partie des détails techniques circulent en ligne. L’équipe PHP, dos au mur, annonce une publication pour le lendemain à 14 h 00 UTC, un jour plus tôt que prévu.

Mais quelque chose de plus troublant apparaît dans les données. Amazon Threat Intelligence identifie une tentative d’exploitation dans sa télémétrie MadPot datée du 17 octobre, soit quatre jours avant toute divulgation publique, depuis une adresse IP liée à un réseau d’anonymisation commercial. Quelqu’un savait. Ou quelqu’un a redécouvert. AWS précise honnêtement que l’origine de ces informations reste inconnue.

Le jour de la publication, des preuves de concept publiques apparaissent en quelques heures. Les pots de miel de watchTowr détectent de l’exploitation dès le 21 octobre. Le 26 octobre, la CISA ajoute les deux CVE à son catalogue des vulnérabilités exploitées. Et fin octobre, une exploitation réussie est confirmée contre une installation Apache avec mod_php en PHP 8.4.26.

Trois jours entre un correctif et une exploitation confirmée. C’est court.


De quoi parle-t-on vraiment ?

Pour comprendre pourquoi cette faille n’est pas « une de plus », il faut saisir une distinction simple : le défaut n’est pas dans votre application, il est dans le runtime qui l’exécute.

Toutes les versions de PHP depuis la 5.4 sont concernées. Wiz a démontré l’exploitabilité sur des images conteneur récentes de WordPress, Drupal et Joomla. Calif a étendu la démonstration à Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony, WHMCS. Mais cette liste est trompeuse, parce qu’elle donne l’impression qu’il s’agit d’un problème de plateforme. Ce n’est pas le cas. Une application « Hello World » tournant sur une version vulnérable l’est tout autant.

Le mécanisme, lui, tient à la façon dont PHP gère la mémoire lorsqu’un traitement de requête s’interrompt brutalement, typiquement quand le memory_limit est atteint, normalement, PHP alloue de la mémoire pour traiter une requête, puis la libère proprement. Quand la sortie est brutale, ce nettoyage peut être contourné : des pointeurs non initialisés ou des entrées de cache survivent là où ils ne devraient plus exister. La classification officielle est parlante : CWE-824, accès à un pointeur non initialisé.

Pour la CVE-2026-109619, on est sur un use-after-free : un processus worker conserve l’état d’une requête alors que la mémoire correspondante a déjà été libérée. S’il traite ensuite une autre requête, il peut atteindre cet état résiduel avant que l’initialisation normale ne le réécrive.

Trois mécanismes du moteur sont touchés : la gestion de session liée à upload_progress, le cache de classes OPcache, et la génération de traces lors d’erreurs fatales. La chaîne d’exploitation décrite par Akamai suit cinq étapes : accéder à upload_progress, saturer la mémoire, déclencher la libération, réaliser un heap spray, déclencher l’exploitation. 

Rien de trivial, mais rien d’insurmontable non plus une fois la recette publique ! L’angle mort : la fuite mémoire£.
C’est la partie dont on parle le moins, et c’est probablement celle qui devrait le plus nous occuper. Wiz a démontré qu’un attaquant peut lire des données sensibles directement dans la mémoire du processus PHP : mots de passe, jetons, clés d’API, sans jamais obtenir d’exécution de code. Le parallèle avec Heartbleed est assumé dans leur analyse.

Autrement dit : même dans un environnement où l’exploitation en RCE reste difficile, une fenêtre d’exposition prolongée peut justifier une rotation des secrets manipulés par ce processus. C’est une décision inconfortable, parce qu’elle coûte cher et qu’elle se prend sans preuve de compromission. Mais attendre la preuve, dans ce cas précis, revient à attendre trop tard.

Le retour de bâton : ni panique, ni déni

Il faut ici résister à deux réflexes symétriques.

Le premier consiste à crier au scénario catastrophe. Sansec a été parmi les premiers à tempérer : l’exploitation de masse s’est révélée moins probable qu’anticipé, parce que les exploits publics ne fonctionnent pas contre une installation PHP par défaut. Une attaque réussie suppose une connaissance fine de la cible et des conditions particulières sur celle-ci. Cela ne dispense pas de corriger, cela évite simplement de passer trois nuits blanches pour rien.

Le second réflexe consiste à se rassurer trop vite. Arctic Wolf relève que de nombreuses requêtes estampillées « PHP2Shell » observées en production recyclent en réalité des techniques plus anciennes de session poisoning et de désérialisation, sans rapport avec le mécanisme de corruption mémoire sous-jacent. Recorded Future signale par ailleurs une prolifération de dépôts GitHub proposant des preuves de concept, dont certains reposent sur des théories d’exploitation invalidées depuis. Une alerte de scan ne vaut donc pas preuve de compromission et l’absence de vague massive ne signifie pas absence d’intrusion ciblée. Arctic Wolf mentionne d’ailleurs une activité attribuée au botnet Potassium.

Ce que nous avons fait, et ce que je recommande

L’inventaire d’abord, et c’est là que le bât blesse. La CISA insiste sur un point que nous connaissons tous mais que nous appliquons mal : PHP est très souvent un composant embarqué dans un autre logiciel, et sa présence n’est pas directement observable. Au-delà des serveurs web, il faut penser aux équipements, aux outils de supervision, aux solutions métier packagées. Tant que cette cartographie n’est pas fiable, la question « suis-je exposé ? » reste sans réponse.

Ensuite, la correction : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, en priorisant l’exposé à Internet. Pour les versions 8.1 et antérieures, sorties du support, la CISA recommande purement et simplement la mise hors ligne jusqu’à mise à niveau. C’est radical, et c’est proportionné.

En attendant un cycle de maintenance, deux mesures utiles. 

Positionner session.upload_progress.enabled=0, un palliatif recommandé par l’équipe PHP elle-même avant la publication du correctif. 
Et accepter qu’un pare-feu applicatif n’offre qu’une protection partielle et temporaire, utile, pas suffisante.

Pour la détection, le motif à surveiller est concret. Huntress documente un incident où un processus FastCGI écrivait de façon répétée un petit fichier PHP contenant des marqueurs aléatoires dans le premier répertoire temporaire inscriptible, l’exécutait, puis le supprimait. La surveillance des répertoires temporaires et des créations de fichiers PHP éphémères est donc à privilégier. La CISA a publié une règle SIGMA allant dans ce sens.

Enfin, gardez un œil sur CVE-2026-115560, une troisième vulnérabilité associée toujours sans correctif. Selon l’équipe PHP, elle n’est exploitable que dans une combinaison inhabituelle de configuration et de code applicatif. À suivre, sans urgence immédiate.

La vraie leçon

Il y a, dans cette affaire, un enseignement qui dépasse largement le cas de PHP.

Nous savons inventorié nos frameworks. Nous suivons à peu près nos bibliothèques. Nous suivons très mal notre interpréteur, ce composant discret qui porte l’intégralité de notre pile applicative et dont les versions en production couvrent dix ans d’histoire. Une SBOM qui s’arrête aux dépendances applicatives est une SBOM incomplète, et c’est exactement la question que la CISA place en tête de ses recommandations.

Mais il y a autre chose, et c’est peut-être plus dérangeant.

Wiz écrit que ces défauts étaient présents depuis des décennies, mais que démontrer leur exploitabilité exigeait une chaîne d’étapes exceptionnellement complexe, « à la limite de ce que des chercheurs humains pouvaient réaliser en pratique ». Les modèles d’IA frontière ont substantiellement abaissé cette barrière. Un défaut dormant pendant dix ans est devenu, en quelques mois, un exploit fonctionnel entre les mains de n’importe qui.

Ce basculement, de la découverte artisanale vers la découverte industrialisée, ne concerne pas seulement PHP. Il concerne l’ensemble du logiciel que nous exploitons. Et il mérite qu’on s’y arrête sérieusement.