PHP2Shell ne sera pas la dernière. Voici où la prochaine apparaîtra en premier.

Le 17 octobre, le réseau de pots de miel d’Amazon a enregistré une tentative d’exploitation de PHP2Shell depuis une adresse IP anonymisée. Pourtant, la divulgation publique n’a eu lieu que quatre jours plus tard.

Lorsque PHP a publié ses correctifs, le 21 octobre, les détails techniques avaient déjà fuité, des exploits de preuve de concept circulaient largement et les tentatives d’exploitation se multipliaient. Le problème venait de deux vulnérabilités critiques d’exécution de code à distance sans authentification dans le moteur PHP lui-même (CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9.2 selon CVSS v4.0) — celles que nous connaissons aujourd’hui sous le nom de PHP2Shell.

Notre équipe de recherche en sécurité a expliqué ce qui s’est passé et ce que vous devez faire : quelles versions installer, quelles mesures d’atténuation mettre en place pour réduire l’exposition en attendant la mise à jour, et où chaque composant de la plateforme Snyk détecte le problème.

Cet article reprend là où notre équipe de recherche en sécurité s’est arrêtée. Nous voulons parler des enseignements de cette réponse : où se trouve ce type d’exposition et d’où il vient, pourquoi répondre rapidement dépend du travail accompli des mois plus tôt, et pourquoi la prochaine vulnérabilité est déjà en chemin.

Pourquoi PHP2Shell a-t-il posé problème à des équipes dont le code était sain ?

Eh bien, parce que les vulnérabilités se trouvent en dessous du code. Qu’est-ce que cela signifie ? Les deux CVE mentionnées surviennent au cours du cycle de vie des requêtes du moteur PHP, ce qui les rend exploitables avant même l’exécution du code de l’application. Sur Apache avec mod_php, un seul élément était nécessaire pour exploiter la faille : une requête sans authentification.

Prenez un instant pour y réfléchir. Vous aviez probablement effectué des revues rigoureuses, écrit du code sain et maintenu un arbre de dépendances bien organisé, tout cela au-dessus du véritable problème. La première question à laquelle chaque équipe a dû répondre était : où PHP traitait-il les requêtes, et quelqu’un pouvait-il exploiter la faille à cet endroit, à ce moment-là ?

La question concernait les applications en cours d’exécution. C’est toujours par cette même question que commencent les attaquants.

Quel inventaire vous indique où PHP est exécuté ?

Chaque type d’inventaire vous en révèle une partie.

PHP arrive en production via un Dockerfile, un paquet de distribution, une image de plateforme ou une installation manuelle. Une contrainte "php": ">=8.2" dans composer.json indique les versions acceptées par une application, mais la version déployée dépend de la méthode utilisée pour l’installer. Les analyses de conteneurs détectent PHP installé à partir de paquets de distribution dès que chaque distribution publie son avis de sécurité. En revanche, PHP compilé à partir des sources, y compris les images Docker officielles de PHP, n’entre pas dans ce périmètre. (Encore une fois, l’article de notre équipe de recherche indique précisément quelle vue de Snyk détecte quelle partie de cette réalité.)

Il y a ensuite la chaîne de version. VirusTotal identifie par empreinte environ 5,1 millions d’adresses IP exécutant PHP, mais seulement 1,1 million d’entre elles environ indiquent une version : près de quatre sur cinq la masquent. Leur résumé est l’un des plus clairs que nous ayons lus sur le sujet : « Si vous cherchez uniquement une chaîne de version, vous ne voyez que la partie du problème qui la révèle. »

Le véritable risque se trouve dans l’écart entre ce que savent vos outils d’analyse internes et ce qui répond réellement depuis l’extérieur. Les attaquants ciblent votre URL, et PHP2Shell en est le cas le plus évident que nous ayons vu. Toute personne qui cherche à exploiter cette vulnérabilité finit par poser la même question : PHP répond-il à cette URL ?

À quoi ressemblait la réponse vue de l’extérieur ?

L’avance prise : avant la publication de PHP à 14 h UTC le 21 octobre, Snyk avait déjà publié des avis de sécurité pour les deux CVE. Les projets surveillés étaient donc alertés dès que les versions corrigées étaient connues. Environ 30 minutes après la publication, ces avis indiquaient les plages de versions affectées et les versions corrigées. Les avis des distributions ont suivi au fur et à mesure de leur publication. C’est ce que pouvaient révéler Snyk Container et les analyses des logiciels non gérés.

Trois questions ont guidé Snyk API & Web :

1. Où PHP est-il exécuté ? La découverte répertorie les actifs associés à vos domaines et identifie leur pile technologique. Sélectionnez PHP dans le filtre Tech pour obtenir la liste de chaque hôte et point de terminaison découvert où PHP a été identifié, avec son niveau de risque, son score et sa date de dernière détection. Les numéros de version viennent ensuite, depuis les hôtes eux-mêmes. Comme l’a indiqué notre équipe de recherche, il faut disposer de la liste avant de pouvoir appliquer les correctifs.

2. La faille peut-elle être exploitée ? Dans les 24 heures suivant la publication de PHP, le profil d’analyse complet testait PHP2Shell. Les équipes pouvaient aussi exécuter ce contrôle de leur côté sous la forme d’un profil personnalisé, pour obtenir rapidement une réponse concernant toutes les cibles PHP.

3. Le correctif a-t-il tenu ? Après l’application du correctif, exécutez à nouveau le même profil personnalisé et associez-le à l’avis de sécurité ou au niveau de correctif de votre distribution, car une version corrigée de la distribution peut conserver un numéro de version plus ancien.

En résumé : découverte --> contrôle ciblé --> correctif --> nouvelle vérification. Il s’agit de sonder, d’observer et de déduire, alors que le compte à rebours se mesure désormais en heures. Et c’est précisément le point le plus préoccupant, celui qui nous importe le plus. Pour les équipes qui utilisaient déjà Snyk API & Web, le plus difficile avait été fait avant le 21 octobre : leurs domaines étaient cartographiés et leurs applications configurées comme cibles. Dès que le contrôle a été disponible, il n’a fallu qu’un filtre et une analyse rapide pour agir.

C’est, selon nous, l’un des principaux bénéfices des tests continus depuis l’extérieur : le travail qui permet de répondre dès le premier jour est effectué des mois à l’avance.

Si PHP2Shell peut être détectée depuis l’extérieur, quelle était la difficulté ?

Le temps.

En mai, nous avons expliqué la distinction sur laquelle repose COS. Les vulnérabilités détectables par heuristique sont visibles pour les outils déterministes : envoyer des charges utiles à une application ou une API en cours d’exécution, observer les réponses et en tirer des conclusions. Les vulnérabilités dépendantes du contexte (BOLA, fuites entre locataires et enchaînements de logique métier) ne présentent aucune signature, car elles se situent dans l’écart entre ce qu’une application est censée faire et ce qu’elle fait réellement.

Une fois connue, PHP2Shell pouvait être testée depuis l’extérieur, ce qui la classe clairement parmi les vulnérabilités détectables par heuristique. La difficulté, la contrainte, résidait dans le délai entre la divulgation et le lancement d’un contrôle sur tout ce que vous exposez. C’est la fenêtre dont disposent les attaquants pour exploiter la faille. Cette fois-ci, elle s’est ouverte quatre jours avant la divulgation.

La divulgation a continué d’évoluer. Le 23 octobre, le projet PHP a décrit un contournement partiel (CVE-2026-115560) qui s’applique lorsqu’une application change de gestionnaire de sérialisation des sessions avec ini_set() avant de démarrer la session, avec le suivi de progression des téléversements activé. Les conditions préalables sont rares, mais même une conclusion tirée le mercredi nécessitait une nouvelle vérification le vendredi. Une réponse ponctuelle devient obsolète en quelques jours.

Pourquoi PHP2Shell ne sera-t-elle pas la dernière ?

Il y a trois raisons à cela, liées à la manière dont ces vulnérabilités ont été découvertes :

1. Parce qu’elles ont été découvertes avec l’aide de l’IA, dans un moteur qui fait fonctionner le Web depuis trois décennies. Notre équipe de recherche l’a dit clairement : « À l’ère des LLM et des agents, tout le monde utilise encore des serveurs. » Et les attaquants disposent désormais du même type de modèle que celui qui a découvert ces vulnérabilités.

2. Une cadence accélérée. Manoj Nair, directeur technique et directeur de l’innovation de Snyk, l’a expliqué en septembre : « Le type de faille grave que l’IA met désormais au jour dans des logiciels largement utilisés — une découverte qui survenait autrefois une ou deux fois par an et bouleversait le trimestre de tout le monde — se produit plusieurs fois par semaine, d’après ce que j’observe. »

3. Un rythme beaucoup plus soutenu. CJ Moses, RSSI d’Amazon Integrated Security, a tiré deux enseignements de PHP2Shell qui s’appliquent bien au-delà de cette vulnérabilité. Les défenseurs « ne devraient pas supposer que la date de divulgation publique correspond à la première exploitation. » Et « pour des raisons structurelles, le délai entre la publication d’un correctif et l’apparition d’un exploit fonctionnel se réduit, » car l’analyse assistée par l’IA facilite la transformation d’un diff de correctif ou d’un avis de sécurité en exploit fonctionnel. Son conseil pour les vulnérabilités critiques dans les systèmes exposés à Internet : « mesurez les délais d’application des correctifs et d’atténuation en heures. »

Que faut-il pour être prêt la prochaine fois ?

En faisant abstraction des noms de produits, tout se résume à quatre caractéristiques. Évaluez toutes les approches en fonction de ces critères, y compris la nôtre. Ne vous attardez pas aux noms de produits : l’essentiel tient à ces quatre caractéristiques. Évaluez chaque approche à l’aune de celles-ci, la nôtre comprise.

1. Un inventaire établi avant la publication de l’avis. Créé depuis l’extérieur et tenu à jour, pour qu’une nouvelle divulgation se traduise d’abord par un filtre.

2. Des contrôles disponibles en quelques heures. Le délai entre la publication d’un avis et le lancement d’un test constitue la fenêtre des attaquants. Mesurez-le.

3. Des vérifications à la demande. Relancez le même contrôle ciblé jusqu’à ce que le correctif tienne.

4. Des tests qui ne nécessitent aucune signature. Les méthodes heuristiques détectent ce qui a déjà été décrit. Tout le reste demande du raisonnement : des tests qui déterminent ce que votre application est censée faire, puis identifient l’écart avec son comportement réel.

Voici comment cela se traduit dans l’offre de Snyk.

Snyk API & Web couvre les trois premières caractéristiques : la découverte, un moteur que l’équipe tient à jour au fil des divulgations, et des profils ciblés que vous pouvez exécuter et relancer. Continuous Offensive Security ajoute la quatrième : AI Pentesting analyse votre application comme le ferait un pentester, Agent Red Teaming intervient dès que la reconnaissance repère un LLM dans la pile technologique, et les tests dynamiques, assurés par le moteur de Snyk API & Web, couvrent en continu les classes de vulnérabilités détectables par heuristique. Dans les termes de notre plateforme, c’est Validate : attaquer vos applications en continu pour vérifier que les correctifs tiennent et révéler ce qui reste exploitable.

Il y a aussi la posture. Lors de The AI Security Panel: Unfiltered, le 14 octobre, Manoj a posé la question à laquelle nous revenons sans cesse : « Si un attaquant autonome va vous attaquer, pourquoi ne pas vous attaquer vous-même ? » C’est tout le principe de COS. De notre côté, nous nous efforçons de réduire chacun des délais de cette histoire : entre la publication d’un avis et le lancement d’un contrôle, puis entre le contrôle et la confirmation du correctif.

Où la prochaine apparaîtra-t-elle en premier ?

Quel moteur sera concerné, et quand, personne ne peut le prédire. En revanche, l’endroit où la prochaine vulnérabilité apparaîtra en premier est plus facile à prévoir : votre URL. C’est là que vos tests devraient déjà avoir lieu.

Vous voulez voir ce qu’un attaquant trouverait aujourd’hui sur votre URL ? Réservez une démo d’Evo Continuous Offensive Security et découvrez comment la solution cartographie votre surface d’attaque depuis l’extérieur, vérifie quelles vulnérabilités sont exploitables et relance les tests jusqu’à ce que le correctif tienne.