La dernière mise à jour​​ 

Insikt Group a publié une instance TTP pour PHP2Shell couvrant les exploits publics de preuve de concept (PoC), l’activité observée des exploits et les mesures d’atténuation recommandées. À 19h UTC le 21 octobre 2026 :​​ 

• Statut du correctif : PHP a publié des versions corrigées le 21 octobre 2026 : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.​​ 
• Statut d’exploitation: Bien qu’il existe des rapports faisant état de tentatives émergentes visant PHP2Shell, les reporting disponibles n’établissent pas l’étendue complète de l’exploitation réussie ou de la compromission confirmée (1, 2).​​ 
• Statut PoC : Les dépôts publics prétendent fournir des exploits de preuve de concept (PoC) PHP2Shell, bien que leur efficacité et leur relation avec la vulnérabilité confirmée varient. Par exemple, le chercheur en sécurité J4ck3LSyN a publié deux Présumés PoC mais a ensuite invalidé la théorie du UAF à pointeurs cachés sous-jacente à leurs séquences d’exploitation proposées.​​ 

Comment tout a commencé​​ 

Le 20 octobre 2026, l’équipe de sécurité PHP a annoncé une version de sécurité hors bande pour le 21 octobre à 14h00 UTC afin de corriger deux vulnérabilités critiques, toutes deux classées 9,2 selon CVSS v4.0. PHP a initialement retenu les détails techniques et les versions affectées en attendant une divulgation coordonnée, avertissant que la sortie pourrait être accélérée si des détails de vulnérabilité étaient divulgués ou si une exploitation émergeait.​​ 

Avant la sortie prévue, watchTowr a signalé la reproduction du CVE-2026-109618 et a évalué que la vulnérabilité pouvait permettre l’exécution à distance du code (RCE). Des informations techniques ont ensuite fuité avant une divulgation coordonnée, suscitant une inquiétude croissante quant à une possible exploitation. PHP a publié les correctifs le 21 octobre, accompagnés d’un article de la PHP Foundation à propos de la mise à jour, qui abordait la mise en question d’urgence et les améliorations des processus de sécurité de PHP.​​ 

Le nom « PHP2Shell » vient de Wiz Research, qui a identifié les failles de Calif et OpenAI et les a signalées à PHP en août. L’article de Wiz couvre en profondeur la découverte et la cause profonde.​​ 

La vulnérabilité​​ 

Les deux CVE sont une vulnérabilité de sécurité mémoire impliquant la gestion par PHP de la mémoire des requêtes lors de l’initialisation, de la gestion des erreurs et du nettoyage. Selon Wiz, les défaillances hors mémoire (OOM) et l’état interne stagnant peuvent exposer une mémoire libérée ou partiellement initialisée, permettant potentiellement la divulgation de mémoire, la corruption de la mémoire et l’exécution à distance de code (RCE).​​ 

• CVE-2026-109618 : Une vulnérabilité liée à l’OOM impliquant une mémoire de requête partiellement initialisée. Wiz a identifié un usage après libre (UAF) dans le sérialiseur de téléchargement-progression de session ainsi qu’un défaut connexe pouvant révéler la mémoire ouvrière PHP. Wiz a démontré un RCE non authentifié contre WordPress, Drupal et Joomla.​​ 
• CVE-2026-109619 : Une vulnérabilité à état stagnant impliquant des PHP globals qui conservent des références à la mémoire de requête libérée. Wiz a identifié un UAF impliquant des backtraces d’erreurs fatales et un défaut distinct de confusion de type d’OPcache. Wiz a démontré un RCE non authentifié face à Drupal et WordPress.​​ 

La vulnérabilité affecte PHP lui-même plutôt qu’une application web particulière. Certains chemins d’exploitation impliquent la fonctionnalité de téléchargement de session de PHP, que VirusTotal note exister depuis PHP 5.4.0 et qui est activée par défaut. Parce que l’exploitation dépend de l’exécution PHP, de la configuration du serveur et des chemins d’exécution accessibles, même les sites web disposant d’un code applicatif sécurisé peuvent être vulnérables.​​ 

PHP a identifié les versions suivantes affectées et corrigées. Les branches PHP plus anciennes et non prises en charge ne sont pas couvertes par ces correctifs spécifiques à la version et ne doivent pas être considérées comme non affectées.​​ 

Rapports d’exploitation active​​ 

Suite à la divulgation de la vulnérabilité PHP2Shell, plusieurs sources ont signalé une activité d’exploitation à l’état sauvage :​​ 

• Patchstack reçu des rapports d’incidents multiples d’exploitation active de la part de partenaires hôtes à 07h34 UTC le 21 octobre, avant la mise à jour de sécurité de PHP.​​ 
• Le CTO de Cloudflare, Dane Knecht, a rapporté avoir observé des attaques précoces ciblant la vulnérabilité. Cloudflare a ensuite déployé une protection contre les pare-feu d’applications web (WAF) contre les vecteurs d’exploitation connus.​​ 

Bien que ces rapports indiquent une activité d’exploitation précoce, les preuves publiques restent insuffisantes pour établir l’ampleur du compromis réussi ou caractériser les TTPs utilisées dans les attaques observées.​​ 

Exploits publics de preuve de concept​​ 

De nombreux dépôts publics GitHub ont vu le jour autour de PHP2Shell, incluant des projets faisant la promotion d’exploits de preuve de concept (PoC), des outils de test de vulnérabilité et des ressources défensives. Plusieurs affirment cibler CVE-2026-109618 et CVE-2026-109619 via des TTPs de corruption mémoire destinées à faire planter les serveurs vulnérables ou à réaliser l’exécution à distance de code (RCE). Cependant, certains s’appuient sur des théories d’exploitation invalidées, et l’existence de code public n’établit pas qu’il exploite avec succès l’une ou l’autre de la vulnérabilité.​​ 

Insikt Group's TTP Instance examine deux scripts PoC publiés par le chercheur en sécurité J4ck3LSyN :​​ 

• poc0_109618.py: Initialement destiné à exploiter CVE-2026-109618 via la fonctionnalité de téléchargement de session de PHP (upload-progress), en utilisant un TTPs de corruption de mémoire proposé pour exécuter des commandes sur un serveur vulnérable.​​ 
• poc1_109619.py: Initialement destiné à exploiter CVE-2026-109619 via un TTPs connexe impliquant des morceaux successifs d’un fichier téléchargé, en tentant de manière similaire d’exécuter du code à distance.​​ 

J4ck3LSyN a ensuite invalidé la théorie de la vulnérabilité des pointeurs en cache sous-jacente à ces TTPs d’exploitation proposées, mais a signalé séparément la reproduction d’un autre problème de sécurité mémoire sans démontrer la RCE.​​ 

D’autres dépôts accessibles publiquement font la publicité d’exploits PHP2Shell, de scripts de test de vulnérabilité et d’environnements de démonstration. Certains continuent de décrire le pointeur en cache invalidé TTPs, tandis que d’autres prétendent utiliser des méthodes d’exploitation différentes. Au moment de cette publication, Insikt Group n’a pas testé de manière indépendante les points de vue de J4ck3LSyN ni d’autres points de vue disponibles publiquement pour leur exactitude ou leur efficacité.​​ 

Échelle et exposition​​ 

Deux scans indépendants sur Internet montrent combien de PHP est exposé, mais ils comptent différemment. Modat compte les services PHP qui rapportent une version lisible et ont été vus dans les 10 jours précédant le 20 octobre. VirusTotal compte les adresses IP au 21 octobre, y compris les serveurs PHP qu’il identifie par des signaux autres qu’une chaîne de version, tels que l’application, les cookies de session et les en-têtes du framework.​​ 

• Modat : 4 384 302 services PHP sur 1 886 612 hôtes uniques. Environ 79 % des services avec une version lisible tournent une branche PHP ne prend plus en charge, et PHP 7.4, en fin de vie depuis 2022, représente 878 761 services, soit plus que n’importe quelle branche prise en charge.​​ 
• VirusTotal : Environ 5,1 millions d’adresses IP fonctionnant sous PHP, dont seulement environ 1,1 million divulguent une version, donc environ quatre sur cinq la masquent. Parmi ceux qui divulguent leur version, environ 758 000 exploitent une branche en fin de vie de 5,4 à 8,1, contre environ 272 000 sur une branche supportée, et le PHP 7,4 à lui seul représente environ 187 000.​​ 

Aucun des deux scans ne compte les hôtes vulnérables confirmés, mais les deux pointent dans la même direction : la plupart des PHP exposés tournent sur des branches en fin de vie qui ne recevront pas de correction officielle. Les scans qui reposent sur des chaînes de version manquent la majeure partie de la surface exposée, et faire tourner la dernière version n’était aucune protection : VirusTotal comptait environ 85 000 adresses IP sur les versions du 24 septembre, les plus récentes disponibles avant la correction.​​ 

Pourquoi cela est important​​ 

• Des millions de serveurs pourraient être exposés : VirusTotal a identifié environ 5,1 millions d’adresses IP fonctionnant sous PHP, mettant en lumière la portée potentiellement étendue de cette vulnérabilité.​​ 
• Même les applications PHP sécurisées sont à risque : Ces défauts peuvent permettre l’exécution de code à distance non authentifié directement en PHP, même lorsque l’application qui s’exécute dessus ne présente aucune vulnérabilité.​​ 
• Les secrets peuvent fuiter sans exécution de code : Wiz a montré que la faille de divulgation mémoire peut exposer des mots de passe, des jetons d’authentification, des clés API et des certificats provenant d’autres requêtes.​​ 
• La fenêtre de correctif s’est effondrée : Les détails ont fuité quelques heures avant la sortie, et les chercheurs en sécurité ont rapporté des tentatives d’exploitation avant que les versions corrigées ne soient disponibles (1, 2).​​ 
• De nombreux serveurs exécutent des versions PHP obsolètes : VirusTotal a constaté que la plupart des serveurs PHP divulguant leurs versions exécutaient des branches en fin de vie qui ne reçoivent plus de mises à jour régulières de sécurité en amont.​​ 
• La compromission peut se propager au-delà du serveur web : VirusTotal a trouvé environ 394 000 hôtes PHP qui exposent également Secure Shell (SSH), environ 233 000 qui exposent MySQL, et environ 68 000 qui exposent le protocole de bureau à distance (RDP).​​ 
• Les journaux peuvent montrer peu de choses : L’exploitation se produit en dessous de la couche applicative, donc les journaux d’application peuvent enregistrer un contexte limité.​​ 

Chronologie des événements​​ 

La divulgation de la vulnérabilité de PHP2Shell s’est déroulée sur plusieurs semaines, débutant par leur découverte en août 2026 et culminant avec une mise à jour d’urgence de sécurité le 21 octobre 2026. Cependant, les détails de vulnérabilité sont devenus accessibles au public avant la sortie coordonnée, ce qui a entraîné des préparatifs défensifs et des rapports d’activités d’exploitation avant la disponibilité des correctifs.​​ 

La chronologie suivante présente les développements clés liés à la découverte, la divulgation coordonnée, les premiers rapports d’exploitation et Recorded Future's réponse.​​ 

• 19 août 2026 : Wiz Research découvre la première vulnérabilité PHP en utilisant des outils de recherche assistés par IA.​​ 
• 20 août 2026 : Wiz Research confirme l’exécution de code à distance non authentifiée (RCE) contre Drupal.​​ 
• 21 août 2026 : Wiz Research confirme un RCE non authentifié contre WordPress.​​ 
• 24 août 2026 : Wiz Research signale en privé la vulnérabilité à l’équipe de sécurité du PHP, lançant ainsi le processus coordonné de divulgation.​​ 
• 21 septembre 2026 : L’équipe de sécurité PHP reconnaît les rapports de vulnérabilité et commence à développer des correctifs coordonnés.​​ 
• 20 octobre 2026 : PHP annonce une mise à jour d’urgence hors bande de sécurité prévue pour le 21 octobre afin de traiter deux problèmes critiques de vulnérabilité.​​ 
• 20 octobre 2026 : Insikt Group publie une note initiale de renseignement mettant en avant les prochaines mises à jour de sécurité PHP.​​ 
• 20 octobre 2026 : Recorded Future développe des signatures Renseignements sur la surface d’attaque pour identifier une exposition potentielle à CVE-2026-109618 et CVE-2026-109619.​​ 
• 21 octobre 2026, 02:29 UTC : Une archive contenant des informations de vulnérabilité fuitées a été soumise pour la première fois à VirusTotal.​​ 
• 21 octobre 2026, 07:34 UTC : Patchstack signale avoir reçu des notifications de multiples incidents d’exploitation active de la part de partenaires hôtes, plusieurs heures avant la mise à jour de sécurité prévue.​​ 
• 21 octobre 2026, 13h52 UTC : PHP publie des mises à jour de sécurité couvrant à la fois la vulnérabilité, avant l’heure de sortie annoncée à 14h00 UTC.​​ 
• 21 octobre 2026, 17:52 UTC : Insikt Group publie une instance tactique PHP2Shell, TTPs, TTPs (TTP) pour soutenir la détection des menaces et l’analyse.​​ 

Notamment, des rapports d’activités d’exploitation ont émergé avant la publication officielle de sécurité, créant une brève période durant laquelle les informations sur la vulnérabilité circulaient publiquement alors que les organisations concernées n’avaient pas de correctif officiel. En conséquence, les utilisateurs de PHP peuvent découvrir des tentatives d’exploitation qui ont eu lieu avant la divulgation officielle du correctif. Les chasseurs de menaces devraient donc prolonger leur période de rétrospection pour les tentatives d’exploitation avant la publication des divulgations de vulnérabilité.​​ 

Analyse indépendante Recorded Future​​ 

Recorded Future's Insikt Group analysé la vulnérabilité de PHP2Shell, les exploits de preuve de concept (PoC) disponibles publiquement, les activités d’exploitation rapportées et les mesures défensives. L’instance de TTP résultante fournit aux défenseurs un contexte technique et des conseils exploitables pour aider à évaluer l’exposition, prioriser la médiation, la correction et identifier les attaques potentielles.​​ 

• PoC publics : Plusieurs dépôts GitHub disponibles publiquement affirment fournir des exploits de preuve de concept (PoC) en PHP2Shell ciblant CVE-2026-109618 et CVE-2026-109619. Ces points de bord se concentrent sur l’exploitation des failles de sécurité mémoire PHP pour obtenir une exécution à distance du code, bien que leur efficacité varie, et certains reposent sur des TTPs d’exploitation qui ont ensuite été invalidés.​​ 
• Activité d’exploitation : Les fournisseurs de sécurité ont signalé des tentatives d’exploitation émergentes ciblant PHP2Shell, bien que l’ampleur de l’exploitation réussie reste incertaine, et que les indicateurs confirmés de compromission (IoC) restent limités. L’instance TTP de Insikt Groupinclut des signes d’alerte potentiels que les défenseurs peuvent surveiller, tels que des requêtes web inhabituelles, des erreurs PHP et une activité serveur suspecte.​​ 

Ce que vous devez faire maintenant​​ 

Les organisations exploitant des applications basées sur PHP doivent prioriser le correctif des systèmes vulnérables, évaluer leur exposition et surveiller toute exploitation potentielle. Compte tenu des rapports d’activités d’exploitation avant la mise à jour coordonnée de sécurité, les organisations devraient également enquêter sur la possibilité que les systèmes affectés aient été compromis avant la disponibilité des correctifs.​​ 

Insikt Group recommande les mesures suivantes pour atténuer les risques associés à PHP2Shell :​​ 

• Priorisateur Corrections et corrections : Mettre à jour les déploiements PHP affectés vers les versions correctes correctes, prioriser les applications connectées à Internet et les infrastructures critiques. Les organisations utilisant des versions PHP non prises en charge doivent migrer vers les versions prises en charge ou obtenir des correctifs de sécurité maintenus par le fournisseur. Assurez-vous que la médiation et la correction incluent des composants PHP intégrés dans des applications tierces, des conteneurs et des services gérés.​​ 
• Identifier les actifs exposés et valider la médiation, correction : Inventorier les déploiements PHP dans les environnements organisationnels et évaluer l’exposition en fonction de l’accessibilité, de la configuration et de la critique commerciale. Recorded Future clients devraient utiliser Renseignements sur la surface d’attaque pour identifier les actifs potentiellement vulnérables à Internet et valider les efforts de réparation et de correction.​​ 
• Mettre en œuvre des contrôles de sécurité compensateurs : Lorsque le correctif immédiat n’est pas possible, restreindre l’accès externe aux systèmes vulnérables et mettre en place une protection WAF applicable, un filtrage des requêtes et un renforcement de la configuration PHP. Assurez-vous que les serveurs d’origine ne peuvent pas être accessibles directement pour contourner les défenses périmétriques. Ces mesures peuvent réduire l’exposition à certains TTPsd’exploitation, mais ne doivent pas être considérées comme des substituts au patching.​​ 
• Surveillez l’exploitation et enquêtez sur les compromissions potentielles : Examinez la télémétrie des serveurs web, des applications et des points de terminaison pour détecter des requêtes HTTP anormales, des défaillances de processus PHP, des exécutions de commandes inattendues et d’autres indicateurs d’activité malveillante. prioriser l’examen des activités à partir du 20 octobre 2026 et étudier les systèmes potentiellement compromis. Lorsque des compromis sont identifiés, il faut initier des procédures de réponse incident et faire tourner les Identifiants potentiellement exposés.​​ 

Recorded Future clients peuvent accéder aux Insikt Group PHP2Shell TTP Instance, Validated Intelligence Event et Renseignements sur les vulnérabilités Cards® pour CVE-2026-109618 et CVE-2026-109619 dans la Recorded Future Intelligence Operations Platform. Recorded Future continuera de suivre les développements liés à PHP2Shell et fournira des renseignements mis à jour dès que des informations supplémentaires seront disponibles.​​ 

Insikt Group respecte des procédures de divulgation responsables dans la conduite de ses recherches.​​ 

À propos Insikt Group^®​​ 

Insikt Group de Recorded Future , la division de recherche sur les menaces de l'entreprise, comprend des analystes et des chercheurs en sécurité possédant une vaste expérience au sein des gouvernements, des forces de l'ordre, des forces armées et des agences de renseignement. Sa mission est de produire des renseignements qui réduisent les risques pour les clients, permettent d'obtenir des résultats concrets et préviennent les perturbations des activités.​​ 

Ressources connexes​​ 

Découvrez les points de vue d'experts, les rapports et les outils pour renforcer votre stratégie de cybersécurité.​​