La publication coordonnée de la version de PHP pour les CVE-2026-109618 et CVE-2026-109619 était prévue le 21 octobre à 14 h 00 UTC. D’après la télémétrie de notre Next-Gen WAF, des outils portant le nom de la faille effectuaient des scans plus de neuf heures auparavant. Au moment de la publication de la version, plus de 100 adresses IP sources avaient utilisé des outils estampillés PHP2Shell, sous plus de deux douzaines de noms d’outils différents. L’un de ces outils était un kit pour exploiter dont l’Agent utilisateur contenait le numéro Common Vulnerability and Exposure.

Cet article décrit les premières manifestations de ce trafic, explique comment distinguer le véritable trafic PHP2Shell de celui de deux campagnes similaires menées en parallèle, et indique les mesures à prendre pour les applications de votre entreprise qui utilisent PHP.

Anatomie des bogues

PHP2Shell est le surnom donné à deux vulnérabilités PHP critiques. Toutes deux ont un score CVSS de 9,2 et peuvent permettre une exécution de code à distance sans authentification :

• CVE-2026-109618 : un manque de mémoire peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées. Lors du nettoyage de la requête, ces données sont alors considérées à tort comme fiables.

• CVE-2026-109619 : un état interne peut persister après la libération de la mémoire sur laquelle il repose, puis être récupéré par une requête ultérieure traitée par le même processus de travail.

Pour toute personne cherchant à détecter PHP2shell, il est important de noter qu’il n’existe aucune chaîne de charge utile à rechercher. Exploiter est une condition : faire échouer la requête précisément au mauvais moment. 

Selon PHP, toute installation qui traite des requêtes web est exposée à un risque, notamment celles utilisant PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ou LiteSpeed. PHP attribue à mod_php le niveau de risque le plus élevé. 

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures ne bénéficient d’aucun correctif en amont.

Chronologie

Le déroulement de la divulgation et l’apparition des outils liés à PHP2shell. Toutes les heures sont indiquées en UTC. Les événements liés à la divulgation sont présentés tels qu’ils sont décrits dans l’analyse rétrospective de la PHP Foundation et dans les avis de sécurité consignés sur GitHub.

Les identifiants des CVE PHP2shell (2026-109618 & 109619) ont fuité sans détails techniques, et des outils portant le nom PHP2shell sont apparus dans notre télémétrie environ huit heures après la vidéo de l’exploitation. Le premier outil nommé et le premier kit pour exploiter que nous avons observés sont tous deux apparus avant la version anticipée des images corrigées. Nous ne ferons pas de suppositions sur ce qui a motivé l’apparition de tel ou tel outil, mais au moment de la version coordonnée, les activités de scan étaient déjà bien engagées.

La botte de foin

Depuis l’apparition du premier outil dont le nom contient PHP2shell jusqu’à midi le 22 octobre, nous avons enregistré environ 250 000 requêtes provenant d’outils dont le nom contient PHP2shell, émises depuis quelque 3200 adresses IP publiques.

Bien entendu, tous les outils d’analyse ne sont pas utilisés à des fins d’attaque. Environ un tiers de ce trafic se présente comme défensif : "vérification autorisée de l’exposition", "vérification de l’état des correctifs", "sans exploiter". De nombreuses organisations vérifiaient leurs propres environnements, et c’est une bonne chose. Ces autodésignations sont des affirmations sans preuve, mais elles correspondent au comportement de ces requêtes : de petites sondes inoffensives.

Requêtes provenant d’outils dont le nom contient PHP2shell, par type d’outil (du 21 octobre à 3 h 59 UTC au 22 octobre à midi, chiffres arrondis). 

La suite est plus disparate, et les choses ont évolué rapidement. Un outil d’inventaire des versions de PHP est passé de la version 4.0 à la version 7.2 en onze heures environ.

Des outils qui évoluent aussi vite rendent les signatures fondées sur les chaînes d’Agent utilisateur stale en moins d’une journée.

Les aiguilles

Jusqu’à présent, le moyen le plus fiable de distinguer le trafic à exploiter du reste est la chaîne de délimitation multipart. Chaque kit d’exploitation que nous avons trouvé utilise une chaîne de délimitation fixe ou suivant un modèle dans son en-tête Content-Type. Nous avons ainsi identifié plus de dix kits potentiels, dont cinq directement liés à PHP2shell par leur nom, leur Agent utilisateur ou leur comportement.

Le kit le plus répandu se présente comme suit :

• POST /index.php (ou /), Agent utilisateur php2shell-109618

• Content-Type: multipart/form-données; boundary=B7kQpoc618

• un corps multipartite de taille fixe et un ensemble minimal d’en-têtes

Il cible également des adresses IP brutes plutôt que des noms d’hôte, et envoie une ou deux requêtes par hôte. Il s’agit d’un balayage massif de l’espace d’adressage IP, et non d’une campagne ciblant des sites particuliers. 

La taille du corps varie considérablement d’un kit à l’autre : ne vous fiez donc pas uniquement aux seuils de taille pour repérer ce trafic.

Deux campagnes similaires à écarter en premier

Si vous recherchez PHP2shell dans vos Log, deux autres campagnes compliqueront vos recherches.

React2Shell (CVE-2025-55182). Deux signatures circulent pour PHP2shell : des requêtes multipart transmises par blocs sans en-tête Content-Length, et des corps de requête remplis de longues suites de lettres A. Pendant l’heure que nous avons mesurée, React2Shell représentait respectivement 98,6 % et 99,9 % des correspondances avec ces signatures. La signature de remplissage correspondait déjà presque exclusivement à React2Shell la veille de la sortie de la version. React2Shell envoie des requêtes en masse vers tous les chemins, notamment /xmlrpc.php et /wp-login.php. Le moyen le plus simple de les distinguer est l’en-tête de requête Next-Action, que les actions serveur de Next.js utilisent, mais que PHP n’utilise jamais.

Pourcentage de chaque signature "PHP2shell" en circulation qui relève en réalité de React2Shell, mesuré à partir de l’en-tête Next-Action des requêtes POST envoyées aux points de terminaison PHP, le 21 octobre de 21 h à 22 h UTC. À la même heure, la veille de la sortie de la version : dans 99,7 % des cas, la signature de remplissage correspondait déjà à React2Shell.

wp2shell. Il s’agit d’une tout autre vulnérabilité : une RCE sans authentification affectant le cœur de WordPress, divulguée en juillet 2026. L’outil associé envoie de volumineux corps multipart à index.php de WordPress, avec un délimiteur commençant par ----wp2shell. Il était actif bien avant que PHP2shell soit rendu public. Le comptabiliser reviendrait donc à inventer une activité php2shell "avant divulgation" qui n’a pas existé.

Un enseignement commun aux deux cas : une signature fondée sur la structure d’une requête décrit un type de requête, et non un hacker. Comparez les données à une référence établie avant la divulgation, puis ventilez toute hausse selon un en-tête ou un délimiteur permettant d’identifier les requêtes avant d’en attribuer la cause.

Ce que vous pouvez ou non voir depuis la périphérie

Les tentatives d’exploitation sont visibles en périphérie, mais leur réussite ne l’est pas. PHP2shell fonctionne en provoquant le plantage ou la corruption d’un processus de traitement PHP. De l’extérieur, une tentative réussie peut donc ressembler à une tentative échouée. Si vous pensez avoir été ciblé, c’est sur le serveur d’origine que vous trouverez la confirmation :

• Logs d’erreurs PHP-FPM

• Logs d’erreurs Apache indiquant des plantages de processus de travail (par exemple, des entrées AH00051 "child pid … exit signal")

• Connexions sortantes inattendues établies par des processus PHP, puisqu’un shell à connexion inverse génère du trafic sortant depuis le serveur d’origine

Ce que PHP2Shell révèle sur l’IA

L’IA facilite assurément la découverte des vulnérabilités, et ce, bien plus rapidement que par le passé. Environ un jour après l’apparition du premier outil, nous avons observé des dizaines d’outils identifiés par leur nom, provenant d’environ 3200 adresses IP, et l’un de ces outils est passé de la version 4.0 à la version 7.2 en une dizaine d’heures. 

Nous ne pouvons pas déterminer avec certitude si certains d’entre eux ont été écrits à l’aide de l’IA. Ce que nous constatons, en revanche, c’est que le trafic lui-même est ordinaire : les kits envoient un corps multipartite fixe à des adresses IP brutes, à raison d’une ou deux requêtes par hôte, depuis une infrastructure VPN et d’hébergement du même type que celle utilisée pour la plupart des balayages. Quel que soit le degré d’assistance apportée par l’IA, nous constatons que le paysage des menaces s’étend et évolue de plus en plus vite.

Et jusqu’à présent, la défense reste avant tout une affaire humaine. Les équipes de défense ont vérifié leurs propres systèmes et étiqueté le trafic. Les chasseurs de menaces ont partagé des signatures qui, en réalité, correspondaient presque toutes à une autre campagne. L’application de correctifs, la définition d’un état de référence, et l’examen des Log des serveurs d’origine restent des tâches largement effectuées par des personnes, même avec l’aide de l’IA, et nécessitent une réflexion humaine pour déterminer quelles défenses à plusieurs niveaux mettre en place, et où les déployer.

Les mesures à prendre maintenant

1. Appliquez des correctifs. Passez à l’une des versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou à la formule corrigée de votre distribution. Si vous utilisez la version 8.1 ou une version antérieure, contactez le distributeur de votre formule au sujet des correctifs rétroportés, ou effectuez une mise à niveau.

2. Ne vous laissez pas entraîner sur de fausses pistes. L’en-tête Agent utilisateur, l’Adresse IP et la taille des corps de requête peuvent tous vous induire en erreur lors d’une recherche de menaces. Le véritable indice se trouve dans la chaîne du délimiteur multipart.

3. Écartez React2Shell et wp2shell avant de comptabiliser quoi que ce soit comme du PHP2shell.

4. Soyez prudent avec les listes de blocage d’adresses IP. Plusieurs adresses IP figurant sur les listes diffusées au sujet de cette vulnérabilité sont des points de sortie VPN ou Tor, ou des adresses résidentielles et mobiles véhiculant du trafic ordinaire. Les bloquer pénalise de vrais utilisateurs.

5. Clients de Fastly Next-Gen WAF : pour les applications protégées par Next-Gen WAF, activez le signal couvrant à la fois CVE-2026-109618 et CVE-2026-109619. Il s’agit d’une règle fondée sur un modèle, spécifique à une CVE, qui fait office de correctif virtuel en recherchant des signes structurels d’exploitation.
   Consultez l’article de Fastly sur la protection proactive pour en savoir plus.
   

Remarque : nous vous recommandons également d’envisager d’activer l’option « Automatic Common Vulnerability and Exposure Virtual Patching » dans « Workspace Configuration », comme illustré ci-dessous :

Indicateurs

Comment nous avons procédé aux mesures

Ces chiffres proviennent de la télémétrie des requêtes de Fastly Next-Gen WAF pour la période du 20 au 22 octobre 2026. La chronologie de la divulgation provient du rapport post-mortem de la PHP Foundation et des registres des avis de sécurité de GitHub. Ces décomptes constituent des bornes inférieures : nous ne pouvons rendre compte que des requêtes que notre WAF a observées et enregistrées, et certaines données relatives aux en-têtes proviennent d’heures d’échantillonnage au cours desquelles des correspondances ont été relevées, plutôt que de journées complètes.

Consultez La protection proactive de Fastly contre PHP2Shell, les vulnérabilités critiques PHP RCE CVE-2026-109618 et CVE-2026-109619 pour obtenir des informations plus récentes.