PHP2Shell : deux failles critiques au cœur du Web

PHP2Shell trouve son origine dans la découverte de deux vulnérabilités critiques au sein même de PHP. Contrairement à de nombreuses failles Web, le problème ne se situe pas dans un site, un plugin ou un système de gestion de contenu particulier : il touche directement le moteur PHP chargé d'exécuter le code côté serveur.

Les deux vulnérabilités ont été référencées sous les identifiants CVE-2026-109618 et CVE-2026-109619. Dans certaines conditions, elles peuvent permettre à une requête spécialement conçue de provoquer une corruption de l'état interne de PHP et, à terme, d'obtenir une exécution de code à distance sans authentification.

Leur divulgation devait initialement être coordonnée afin de laisser aux différents acteurs concernés le temps de préparer leurs protections. Mais des informations sur les vulnérabilités, notamment leurs identifiants CVE et certaines mesures de réduction du risque communiquées à des opérateurs sensibles, ont commencé à circuler publiquement avant la date prévue. Le calendrier a alors été accéléré.

Le 21 octobre 2026, l'équipe PHP a publié en urgence de nouvelles versions corrigeant les deux vulnérabilités. L'avis de sécurité officiel appelle l'ensemble des utilisateurs de PHP à effectuer la mise à jour immédiatement.

Des tentatives d'exploitation avant même la divulgation publique

L'un des éléments les plus importants est apparu après la publication des correctifs. En analysant rétrospectivement les données de son infrastructure de détection, Amazon Threat Intelligence a identifié une tentative visant PHP2Shell dès le 17 octobre 2026.

Cette activité précède de quatre jours la publication officielle des correctifs. Elle montre qu'au moins un acteur cherchait déjà à exploiter les vulnérabilités alors que leurs détails n'étaient pas encore officiellement accessibles au public.

D'autres acteurs de la cybersécurité ont également observé des requêtes ou des tentatives d'exploitation avant la divulgation. Cela ne signifie pas que toutes ces attaques ont réussi, ni que les serveurs visés ont nécessairement été compromis. Mais cela réduit fortement la période pendant laquelle les administrateurs pouvaient considérer que le risque ne commencerait qu'avec la publication des failles.

Quelles failles sont concernées ?

PHP2Shell ne correspond pas à une vulnérabilité unique. Ce nom regroupe deux failles distinctes découvertes dans le fonctionnement interne de PHP : CVE-2026-109618 et CVE-2026-109619. Toutes deux peuvent conduire à une exécution de code à distance, mais elles n'empruntent pas le même chemin pour y parvenir.

Dans les deux cas, le problème se situe dans la manière dont PHP gère certaines données en mémoire pendant le traitement des requêtes Web. Un attaquant capable de provoquer une succession précise d'événements peut amener PHP à manipuler des données qui ne se trouvent plus dans l'état attendu.

CVE-2026-109618 : provoquer une erreur au mauvais moment

La première vulnérabilité concerne la gestion des situations où PHP atteint sa limite de mémoire. Lorsqu'un script ou le traitement d'une requête consomme trop de mémoire, PHP doit normalement interrompre l'opération proprement et libérer les ressources utilisées.

CVE-2026-109618 permet cependant de provoquer cet épuisement de mémoire pendant une phase particulièrement sensible. Certaines données internes associées à la requête peuvent alors rester seulement partiellement initialisées, tandis que PHP poursuit ensuite ses opérations de nettoyage comme si ces données étaient valides.

Pour un utilisateur normal, ce type d'erreur devrait au pire provoquer l'échec d'une requête. Dans ce cas précis, un attaquant peut chercher à contrôler suffisamment l'état de la mémoire pour transformer cette erreur en corruption exploitable et parvenir à exécuter du code dans le contexte du processus PHP.

La vulnérabilité est particulièrement préoccupante avec Apache utilisant mod_php. L'équipe PHP indique qu'une exploitation a été démontrée dans cette configuration avant même que le code de l'application Web ne soit exécuté. Une page de connexion ou les contrôles d'accès développés directement dans l'application ne peuvent alors pas empêcher à eux seuls le déclenchement de la faille.

CVE-2026-109619 : des données qui survivent à la requête

La seconde vulnérabilité repose sur un mécanisme différent. Lorsqu'une requête Web est terminée, les données temporaires qui lui appartiennent doivent normalement être libérées et l'état nécessaire à la requête suivante doit être correctement réinitialisé.

Avec CVE-2026-109619, certaines références internes peuvent cependant subsister après que la mémoire vers laquelle elles pointaient a déjà été libérée. Si une nouvelle requête est ensuite traitée par le même processus PHP, cet ancien état peut être réutilisé avant d'avoir été correctement réinitialisé.

En sécurité informatique, cette situation appartient à la famille des erreurs dites use-after-free : un programme continue d'utiliser une zone de mémoire alors qu'elle ne devrait plus être considérée comme valide. En contrôlant suffisamment ce qui vient occuper cette mémoire entre deux opérations, un attaquant peut chercher à influencer le comportement du programme.

Dans le cas de PHP2Shell, les chercheurs ont montré que cette succession d'événements pouvait elle aussi être utilisée pour obtenir une exécution de code à distance. L'exploitation peut nécessiter plusieurs requêtes traitées par le même processus PHP, ce qui la distingue du mécanisme utilisé par CVE-2026-109618.

Deux mécanismes différents, une même conséquence possible

Les deux vulnérabilités ne doivent donc pas être confondues. La première exploite principalement une interruption liée à la mémoire qui laisse des données internes dans un état incohérent. La seconde repose sur la persistance de références vers des données qui ont déjà été libérées.

Leur point commun est leur conséquence potentielle : dans une installation vulnérable et lorsque les conditions nécessaires sont réunies, un attaquant distant peut parvenir à exécuter du code sans disposer au préalable d'un compte sur l'application.

Une autre conséquence a également été démontrée : certaines techniques liées à PHP2Shell peuvent permettre d'exposer le contenu de la mémoire d'un processus PHP. Cette mémoire peut contenir temporairement des informations sensibles manipulées par les applications, comme des mots de passe, des jetons d'authentification ou des clés d'API.

Cette gravité technique ne permet toutefois pas de déterminer à elle seule combien de serveurs sont réellement exploitables. La présence d'une version vulnérable de PHP constitue un premier niveau de risque, mais la configuration du serveur, la manière dont PHP est exécuté et le comportement de l'application peuvent modifier les chemins d'exploitation disponibles.

Qui est réellement exposé ?

L'ampleur potentielle de PHP2Shell tient d'abord à la place occupée par PHP dans l'écosystème Web. Le langage est utilisé directement par des sites, des applications, des systèmes de gestion de contenu et de nombreux produits qui l'intègrent comme technologie côté serveur.

L'équipe PHP considère comme étant à risque toutes les installations PHP qui servent des requêtes Web. Cela inclut notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Cela ne signifie toutefois pas que toutes ces installations peuvent être compromises de la même manière ou avec la même facilité.

La configuration du serveur, la version de PHP utilisée, la manière dont les requêtes sont traitées et le comportement de l'application peuvent modifier les conditions nécessaires à l'exploitation. Parmi les configurations étudiées, l'équipe PHP considère actuellement mod_php comme présentant le niveau de risque le plus élevé.

Des millions d'instances potentiellement vulnérables

Les premières mesures donnent néanmoins une idée de l'étendue de la surface concernée. Selon les données de télémétrie publiées par Unit 42, plus de 22,6 millions d'instances exposées ont été identifiées comme potentiellement vulnérables à CVE-2026-109618 et CVE-2026-109619.

Ce chiffre ne correspond pas à 22,6 millions de serveurs compromis, ni même nécessairement à 22,6 millions de systèmes sur lesquels une exploitation réussie est possible. Il s'agit d'instances exposées présentant des caractéristiques compatibles avec les versions concernées.

D'autres analyses donnent également des ordres de grandeur très élevés. Qualys indique avoir identifié, dans les environnements observés auprès de ses clients, 167 millions d'installations de paquets PHP. Parmi les 156 millions pour lesquelles une version a pu être déterminée, une large proportion se trouve sur des actifs accessibles depuis Internet. Ces données ne représentent toutefois pas l'ensemble du Web et ne doivent pas être extrapolées directement au nombre de serveurs vulnérables dans le monde.

Utiliser PHP ne signifie pas être exploitable

La distinction est essentielle. Un site peut utiliser PHP sans exécuter une version vulnérable. Un serveur peut également disposer d'une version concernée tout en présentant une configuration qui rend un chemin d'exploitation connu plus difficile à reproduire.

À l'inverse, une installation directement accessible depuis Internet, utilisant une version vulnérable et une configuration compatible avec les techniques déjà démontrées présente un risque beaucoup plus important. Avec Apache et mod_php, une exploitation avant l'exécution du code de l'application a notamment été démontrée.

Dans cette situation, la présence d'une authentification dans WordPress, Drupal, Magento ou dans une application développée sur mesure ne constitue pas nécessairement une protection. La vulnérabilité peut être déclenchée au niveau de PHP avant que les mécanismes de sécurité prévus par l'application aient eu l'occasion d'intervenir.

Les logiciels qui embarquent PHP sont également concernés

L'exposition ne se limite pas aux serveurs sur lesquels un administrateur a volontairement installé PHP pour héberger un site. Des produits commerciaux, des appliances et des logiciels peuvent intégrer leur propre environnement PHP pour faire fonctionner une interface Web ou un service d'administration.

Dans ces cas, l'utilisateur peut ne pas avoir directement accès à la version de PHP embarquée et dépendre d'une mise à jour publiée par le fabricant du produit. CERT-EU recommande ainsi de vérifier également les logiciels tiers susceptibles d'intégrer PHP.

Vulnérable, exploitable ou compromis : trois niveaux différents

Une installation est vulnérable lorsqu'elle utilise une version de PHP concernée et non corrigée. Elle devient effectivement exploitable lorsqu'un attaquant peut réunir les conditions nécessaires pour déclencher l'une des vulnérabilités dans son environnement particulier.

Une compromission constitue encore un niveau supplémentaire : elle signifie qu'une exploitation a réellement réussi et que l'attaquant a obtenu un accès ou exécuté des actions sur le système. Les millions d'instances actuellement recensées comme potentiellement vulnérables ne peuvent donc pas être présentées comme autant de machines compromises.

Cette distinction est particulièrement importante pour PHP2Shell. L'étendue de la surface potentiellement concernée est considérable, mais seule l'observation des attaques et de leurs conséquences permet de mesurer l'impact réel de ces vulnérabilités.

Que permet réellement PHP2Shell ?

La conséquence la plus grave associée à PHP2Shell est la possibilité d'obtenir une exécution de code à distance, ou RCE. Concrètement, lorsqu'une exploitation réussit, un attaquant peut parvenir à faire exécuter au serveur des instructions qu'il a lui-même choisies, sans disposer au préalable d'un compte sur l'application.

Cette capacité change complètement la nature de l'incident. L'attaquant ne se contente plus d'envoyer une requête anormale ou de provoquer une erreur dans PHP : il peut commencer à utiliser le processus compromis comme point d'entrée vers le système qui héberge l'application.

Les conséquences ne sont toutefois pas identiques sur tous les serveurs. Le code obtenu par l'attaquant s'exécute dans le contexte du processus PHP compromis. Les permissions accordées à ce processus, la configuration du système d'exploitation, l'isolation mise en place et les services accessibles depuis la machine déterminent alors ce qu'il est possible de faire ensuite.

De l'exécution de code à la prise de contrôle du serveur

Une première action peut consister à lancer des commandes système. Un attaquant peut ainsi chercher à identifier l'environnement dans lequel il se trouve, les utilisateurs présents sur la machine, les logiciels installés, les fichiers accessibles ou encore les connexions réseau disponibles depuis le serveur.

Si les permissions le permettent, il peut également télécharger et exécuter une charge malveillante supplémentaire. Il peut s'agir d'un script, d'un outil permettant de conserver un accès au système, d'un programme destiné à voler des informations ou d'un logiciel permettant d'établir une communication avec une infrastructure contrôlée par l'attaquant.

Une exécution de code à distance ne signifie cependant pas automatiquement que l'attaquant obtient les privilèges les plus élevés du système. Un serveur correctement configuré peut exécuter PHP avec un compte disposant de droits limités. L'attaquant doit alors trouver d'autres moyens d'augmenter ses privilèges s'il souhaite prendre un contrôle plus large de la machine.

À l'inverse, des permissions excessives, des secrets accessibles au processus PHP ou une mauvaise segmentation du serveur peuvent considérablement augmenter les conséquences d'une première exploitation.

Les données de l'application peuvent devenir accessibles

Un processus PHP manipule fréquemment des informations sensibles : identifiants de connexion à une base de données, clés d'API, jetons d'authentification, variables d'environnement, fichiers de configuration ou données transmises par les utilisateurs.

Une fois capable d'exécuter du code dans ce contexte, un attaquant peut chercher à récupérer les informations auxquelles le processus PHP lui-même est autorisé à accéder. La compromission d'un serveur Web peut donc dépasser largement le contenu visible publiquement sur le site qu'il héberge.

Les recherches menées autour de PHP2Shell ont également montré la possibilité de provoquer des fuites de mémoire. Une portion de la mémoire d'un processus PHP peut contenir temporairement des informations provenant de requêtes ou d'applications exécutées par ce même processus.

Cela ne signifie pas qu'une exploitation révèle automatiquement l'ensemble des mots de passe ou des données d'un serveur. Le contenu récupérable dépend de ce qui se trouve effectivement en mémoire au moment de l'attaque. Cette capacité constitue néanmoins un risque supplémentaire, notamment lorsqu'elle permet d'obtenir des informations utiles pour poursuivre une compromission.

Un serveur Web peut devenir un point d'entrée vers le réseau interne

Le risque ne s'arrête pas nécessairement au serveur directement touché. Une application Web communique souvent avec d'autres composants : bases de données, systèmes de stockage, services internes, annuaires d'entreprise, interfaces d'administration ou API qui ne sont pas directement accessibles depuis Internet.

Un attaquant ayant obtenu l'exécution de code sur le serveur peut alors examiner les connexions disponibles depuis cette machine et chercher à atteindre ces ressources internes. Le serveur Web, initialement exposé à Internet, peut ainsi devenir un point de passage vers des systèmes qui ne l'étaient pas.

Cette progression n'est pas automatique. Elle dépend de l'architecture du réseau, des règles de filtrage, des identifiants disponibles sur le serveur et des droits associés. Une infrastructure correctement segmentée peut fortement limiter les possibilités de déplacement après une première compromission.

Vol de données, persistance ou utilisation de la machine

Une fois un accès obtenu, les objectifs peuvent varier selon les acteurs. Certains peuvent rechercher des données ou des identifiants, tandis que d'autres peuvent tenter d'installer un accès persistant afin de revenir sur le serveur même après la disparition du point d'entrée initial.

Une machine compromise peut également être utilisée comme relais, intégrer une infrastructure malveillante ou recevoir des logiciels supplémentaires. Les premières activités observées autour de PHP2Shell montrent déjà que plusieurs types d'acteurs cherchent à exploiter la même surface d'attaque avec des objectifs différents.

Il faut cependant distinguer ces conséquences possibles des actions effectivement constatées. Une vulnérabilité permettant théoriquement une exécution de code ne prouve pas qu'un attaquant a réalisé toutes les étapes qui peuvent suivre : élévation de privilèges, vol de données, déplacement dans un réseau ou installation durable d'un logiciel malveillant nécessitent chacune des conditions supplémentaires.

Que sait-on des attaques déjà observées ?

PHP2Shell n'est désormais plus seulement une vulnérabilité démontrée en laboratoire ou faisant l'objet de tentatives d'exploitation. Des chercheurs ont observé une exploitation réussie permettant l'exécution effective de code à distance sur des systèmes de leurre, tandis que les deux vulnérabilités font désormais l'objet d'une exploitation active reconnue par les autorités américaines.

Le 26 octobre 2026, la CISA a ajouté CVE-2026-109618 et CVE-2026-109619 à son catalogue Known Exploited Vulnerabilities (KEV). Cette inscription marque une évolution importante : les deux vulnérabilités sont désormais officiellement considérées comme exploitées dans la nature.

Cette évolution ne permet toutefois pas de déterminer combien de serveurs ont réellement été compromis. Les millions de requêtes, scans et tentatives recensés depuis la divulgation ne doivent toujours pas être assimilés à autant de compromissions réussies.

Une première tentative détectée dès le 17 octobre

Amazon Threat Intelligence a identifié dans les données de son réseau de leurres MadPot une tentative d'exploitation remontant au 17 octobre 2026, soit quatre jours avant la divulgation publique de CVE-2026-109618 et CVE-2026-109619.

La requête provenait d'une adresse IP associée à un service commercial d'anonymisation. Amazon estime que le ciblage d'un leurre depuis une telle infrastructure est compatible avec l'activité d'un acteur malveillant, mais indique ne pas savoir comment celui-ci avait obtenu des informations sur les vulnérabilités avant leur publication.

Cette observation est importante, mais elle doit être interprétée avec précision. Amazon parle d'une tentative d'exploitation détectée par son infrastructure. L'entreprise indique que ses analyses se poursuivent et qu'il n'est pas établi que cette tentative aurait permis de compromettre un véritable serveur vulnérable.

Plusieurs acteurs étaient déjà actifs avant la publication des correctifs

Le 21 octobre, quelques heures avant la fin prévue de l'embargo, Amazon a détecté plusieurs preuves de concept ainsi que de nouvelles tentatives visant ses capteurs. Les premières apparaissent dans sa télémétrie vers 02:00 UTC, alors que la divulgation officielle était prévue à 14:00 UTC.

Entre 02:00 et 08:00 UTC, d'autres infrastructures anonymisées ont commencé à cibler les mêmes vulnérabilités. Les différences entre les charges utilisées et les infrastructures d'origine conduisent Amazon à considérer que plusieurs acteurs distincts étaient probablement déjà en train de tester PHP2Shell.

F5 Labs a observé une évolution comparable. Son réseau mondial de capteurs a enregistré les premières opérations de scan liées à PHP2Shell à 08:36 UTC le 21 octobre, plus de cinq heures avant la publication officielle des deux CVE et de leurs correctifs.

Certains de ces premiers outils ne cherchaient pas encore à compromettre directement les machines. F5 a notamment observé des requêtes destinées à vérifier si le mécanisme de suivi des téléversements de session de PHP était accessible. Ces sondes servent à identifier les serveurs susceptibles de présenter les conditions nécessaires avant de tenter une exploitation plus complexe.

Une forte accélération après la divulgation publique

La publication des correctifs et des informations techniques a ensuite profondément changé l'échelle de l'activité. Des preuves de concept supplémentaires sont apparues dans les heures suivant la divulgation et ont presque immédiatement commencé à être utilisées contre les infrastructures de détection.

F5 Labs indique avoir enregistré des milliers de tentatives durant les premières heures. Environ 98 % de l'activité observée par ses capteurs concernait CVE-2026-109619, contre environ 2 % pour CVE-2026-109618.

Cloudflare a observé une progression encore plus importante à l'échelle de son réseau. Après la divulgation, le volume de requêtes cherchant à exploiter PHP2Shell est rapidement passé à des centaines de milliers, puis à des millions de tentatives.

Les techniques utilisées évoluent déjà

L'activité observée ne se limite pas à la reproduction d'une seule preuve de concept. Les chercheurs ont constaté plusieurs modèles de requêtes, depuis de simples sondes destinées à vérifier la présence du mécanisme vulnérable jusqu'à des tentatives cherchant réellement à déclencher les conditions nécessaires à l'exécution de code.

Une grande partie des attaques observées exploite le mécanisme session.upload_progress de PHP. Celui-ci permet normalement à PHP de suivre la progression d'un fichier envoyé vers un serveur, mais constitue également l'un des chemins permettant d'atteindre les états mémoire vulnérables utilisés par PHP2Shell.

Les défenseurs ont également constaté une adaptation progressive des requêtes malveillantes. À mesure que des protections ont été déployées, certains attaquants ont modifié leurs charges et leurs méthodes afin de tenter de contourner les règles mises en place par les pare-feu applicatifs.

Des tentatives de déploiement de logiciels malveillants

Les premières campagnes montrent également que l'intérêt pour PHP2Shell dépasse la simple recherche technique. Des acteurs opportunistes ont commencé à tester les vulnérabilités dans le but de déposer ou d'exécuter des charges malveillantes sur les serveurs qui pourraient être compromis.

Parmi les activités étudiées figurent notamment des tentatives associées à des logiciels destinés à intégrer des machines à des réseaux de type botnet. Dans certains environnements surveillés, ces tentatives ont été bloquées avant que la charge malveillante ne puisse être exécutée.

Cela montre un phénomène classique après la publication d'une vulnérabilité critique : plusieurs catégories d'acteurs peuvent réutiliser rapidement les mêmes techniques. Certains cherchent simplement des systèmes vulnérables, d'autres testent des preuves de concept, tandis que des opérateurs malveillants tentent déjà d'en faire un moyen d'accès à des machines qu'ils pourront ensuite utiliser pour leurs propres objectifs.

Une compromission gouvernementale initialement attribuée à PHP2Shell ne peut plus l'être avec certitude

La prudence reste également nécessaire lorsqu'il s'agit d'identifier des victimes. Unit 42 avait initialement associé la compromission d'une agence gouvernementale européenne à l'exploitation de PHP2Shell. Cette attribution a ensuite été retirée le 25 octobre, les chercheurs n'étant finalement pas en mesure de confirmer que l'accès initial provenait de CVE-2026-109618 ou CVE-2026-109619.

Cet épisode illustre la distinction entre exploitation active confirmée des vulnérabilités et attribution d'une compromission particulière à PHP2Shell. La première est désormais établie, la seconde doit être démontrée séparément pour chaque incident.

L'augmentation spectaculaire du nombre de requêtes observées ne permet toutefois pas de mesurer directement le nombre de victimes. Les données disponibles établissent une activité malveillante importante autour de PHP2Shell, mais ne permettent pas de conclure à une compromission généralisée des millions de serveurs potentiellement concernés.

Correctifs, protections et limites

La réponse prioritaire à PHP2Shell consiste à mettre à jour PHP. Les mesures de réduction du risque peuvent rendre certaines techniques d'exploitation plus difficiles, mais elles ne remplacent pas les correctifs.

Les protections déployées en urgence peuvent réduire l'exposition pendant une période de transition, mais elles ne doivent pas conduire à considérer une version vulnérable comme définitivement sécurisée.

Les versions de PHP à mettre à jour

Pour les branches encore maintenues, les versions corrigées sont PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 et PHP 8.5.12. Les administrateurs utilisant ces branches doivent atteindre au minimum la version corrigée correspondante ou une version ultérieure contenant les mêmes correctifs.

Les installations plus anciennes nécessitent une attention particulière. PHP 8.1 et les branches précédentes ne font plus partie des versions bénéficiant du cycle normal de support du projet PHP. Certaines distributions Linux et certains fournisseurs de support longue durée peuvent néanmoins maintenir leurs propres paquets et rétroporter les correctifs de sécurité.

Dans ce cas, le numéro de version affiché ne suffit pas toujours à déterminer si le système est protégé. Une distribution peut conserver une version ancienne de PHP tout en lui appliquant séparément les correctifs nécessaires. Il faut donc vérifier les avis de sécurité et l'état du paquet auprès du fournisseur qui maintient réellement l'installation.

Pour les environnements qui compilent eux-mêmes d'anciennes branches, l'équipe PHP a également publié des correctifs minimaux destinés à PHP 7.4, 8.0 et 8.1. Ces correctifs répondent à PHP2Shell, mais ne rétablissent pas le support général de ces versions : d'autres vulnérabilités non corrigées peuvent toujours y être présentes.

Désactiver session.upload_progress peut réduire la surface d'attaque

Une partie importante des techniques d'exploitation actuellement documentées utilise la fonctionnalité session.upload_progress de PHP. Celle-ci permet normalement de suivre la progression du téléversement d'un fichier et de rendre cette information disponible à l'application pendant l'envoi.

Lorsque cette fonctionnalité n'est pas nécessaire, sa désactivation peut supprimer l'un des chemins utilisés par les exploitations connues. Plusieurs recommandations de sécurité proposent donc cette mesure comme protection temporaire pour les environnements qui ne peuvent pas être mis à jour immédiatement.

Elle ne constitue cependant pas un correctif pour PHP2Shell. Les vulnérabilités se trouvent dans PHP lui-même et d'autres chemins d'exploitation peuvent exister ou être découverts. Une modification de configuration doit donc être considérée comme une mesure de réduction du risque, et non comme une résolution définitive.

Les pare-feu applicatifs peuvent bloquer des attaques, pas supprimer la faille

Les fournisseurs de services de sécurité et de pare-feu applicatifs ont rapidement déployé des règles destinées à reconnaître les requêtes associées aux premières techniques d'exploitation de PHP2Shell. Ces protections peuvent empêcher une partie importante des tentatives connues d'atteindre le serveur PHP vulnérable.

Elles restent néanmoins dépendantes de la capacité à reconnaître le comportement de l'attaque. Or les charges observées depuis la divulgation ont déjà évolué, certains acteurs modifiant leurs requêtes afin d'essayer de contourner les signatures et règles de filtrage déployées en urgence.

Un pare-feu applicatif constitue donc une couche supplémentaire de défense, particulièrement utile lorsqu'une mise à jour immédiate n'est pas possible, mais il ne modifie pas le code vulnérable présent sur le serveur. Le système reste techniquement affecté tant que le correctif PHP n'a pas été appliqué.

Un système impossible à corriger doit être isolé

Lorsque la mise à jour ne peut pas être appliquée immédiatement, la réduction de l'exposition devient prioritaire. Un service vulnérable qui n'a aucune nécessité d'être directement accessible depuis Internet ne devrait pas le rester pendant la période nécessaire à sa sécurisation.

Les autorités de cybersécurité recommandent d'isoler ou de retirer temporairement de l'exposition les systèmes qui ne peuvent pas être corrigés. Dans les environnements les plus sensibles, cette mesure peut aller jusqu'à la mise hors ligne temporaire du service concerné tant qu'une mitigation suffisante n'a pas été mise en place.

Cette approche peut être contraignante pour un service en production, mais elle évite de maintenir volontairement accessible une installation dont une exécution de code à distance sans authentification est publiquement documentée et activement recherchée.

Mettre à jour ne suffit pas toujours à clore l'incident

L'existence de tentatives antérieures à la divulgation publique modifie également la manière dont la réponse doit être menée. Installer le correctif empêche l'exploitation future des vulnérabilités corrigées, mais ne permet pas de déterminer si le serveur avait déjà été compromis auparavant.

Les systèmes exposés avant leur mise à jour peuvent donc nécessiter une recherche de traces d'exploitation : processus inhabituels lancés par PHP, connexions réseau anormales, fichiers récemment créés ou modifiés, téléchargements inattendus et autres comportements qui ne correspondent pas au fonctionnement normal de l'application.

Cette vérification est particulièrement importante pour les systèmes qui étaient accessibles depuis Internet avant le 21 octobre. Les observations d'Amazon montrent qu'une activité liée à PHP2Shell existait déjà au moins quatre jours avant la divulgation publique.

Les correctifs ont-ils déjà été contournés ?

La publication rapide de preuves de concept et de nouvelles recherches a fait apparaître des affirmations selon lesquelles les versions corrigées pourraient elles-mêmes être contournées. Il faut ici distinguer un nouveau chemin d'exploitation, une configuration particulière et un véritable contournement des correctifs appliqués aux deux vulnérabilités initiales.

Une technique permettant d'obtenir une exécution de code sur une version récente de PHP ne démontre pas automatiquement que CVE-2026-109618 ou CVE-2026-109619 restent exploitables après leur correction. Il peut s'agir d'une autre vulnérabilité, d'un comportement propre à l'application ou d'une configuration qui introduit un risque distinct.

Au 24 octobre 2026, les éléments disponibles ne permettent pas d'établir un contournement généralisé des correctifs officiels de PHP2Shell. La découverte de CVE-2026-115560, rendue publique le 23 octobre, correspond à une vulnérabilité distincte et ne constitue pas la preuve que CVE-2026-109618 ou CVE-2026-109619 restent exploitables après correction.

Chronologie et évolution de la situation

Le 17 octobre 2026 constitue actuellement le premier repère connu : Amazon Threat Intelligence a identifié rétrospectivement dans son réseau de leurres MadPot une tentative visant PHP2Shell, quatre jours avant sa divulgation publique.

20 octobre : PHP annonce une mise à jour de sécurité exceptionnelle

Le 20 octobre, l'équipe de sécurité PHP publie un avertissement préalable. Elle annonce pour le lendemain une mise à jour destinée à corriger deux vulnérabilités critiques, toutes deux évaluées à 9,2 sur 10 selon CVSS v4.0.

À ce moment-là, les détails techniques ne sont pas encore rendus publics. PHP demande néanmoins à tous les utilisateurs de se préparer à mettre leurs installations à jour dès la disponibilité des correctifs. L'équipe précise également qu'elle se réserve la possibilité d'avancer la publication si les détails des vulnérabilités deviennent publics ou si une exploitation active est détectée.

21 octobre : correctifs, divulgation et multiplication des tentatives

Dans les premières heures du 21 octobre, avant l'heure prévue pour la divulgation complète, l'activité augmente déjà. Amazon détecte plusieurs preuves de concept et tentatives supplémentaires à partir d'environ 02:00 UTC, provenant de différentes infrastructures anonymisées et utilisant des charges distinctes.

F5 observe également des opérations de reconnaissance liées à PHP2Shell avant la publication officielle. Plusieurs acteurs semblent alors chercher à identifier les serveurs présentant les caractéristiques nécessaires à l'exploitation.

Le projet PHP publie ensuite les correctifs pour CVE-2026-109618 et CVE-2026-109619, accompagnés de nouvelles versions corrigeant les deux vulnérabilités.

Les deux vulnérabilités sont confirmées comme pouvant permettre une exécution de code à distance sans authentification. Leur score CVSS v4.0 de 9,2 les classe parmi les vulnérabilités critiques.

Dans les heures qui suivent la publication, de nouvelles preuves de concept deviennent disponibles et commencent presque immédiatement à apparaître dans les infrastructures de détection. Amazon décrit désormais une exploitation largement tentée dans la nature.

21 et 22 octobre : les protections se déploient pendant que les attaques évoluent

Les fournisseurs de services de sécurité réagissent parallèlement à la publication des correctifs. Cloudflare indique avoir préparé et activé des protections destinées à PHP2Shell avant la divulgation publique, afin de filtrer certaines des requêtes correspondant aux chemins d'exploitation connus.

AWS déploie également des règles spécifiques dans son pare-feu applicatif. Ces protections sont ensuite ajustées à mesure que de nouvelles techniques et de nouvelles formes de requêtes sont identifiées.

Cette période illustre la course qui suit désormais la publication d'une vulnérabilité critique : les administrateurs mettent à jour leurs serveurs, les fournisseurs adaptent leurs protections et les attaquants modifient simultanément leurs charges pour rechercher de nouvelles cibles ou contourner les mécanismes de filtrage.

L'existence de l'activité détectée dès le 17 octobre conduit également Amazon à recommander de ne pas limiter les investigations au jour de la divulgation. Pour PHP2Shell, la recherche de traces suspectes doit remonter au moins jusqu'à cette date.

23 octobre : une troisième vulnérabilité PHP apparaît

Le 23 octobre, une nouvelle vulnérabilité permettant elle aussi une exécution de code à distance est rendue publique sous la référence CVE-2026-115560.

Cette faille doit être distinguée de CVE-2026-109618 et CVE-2026-109619, qui constituent PHP2Shell. Elle concerne une configuration plus inhabituelle et PHP considère son risque comme nettement plus limité.

Elle introduit néanmoins un élément supplémentaire : les versions publiées le 21 octobre pour corriger PHP2Shell ne corrigent pas CVE-2026-115560. Dans l'attente du correctif prévu dans une prochaine version régulière, la recommandation spécifique consiste à désactiver session.upload_progress lorsque cette nouvelle vulnérabilité peut concerner l'environnement.

L'apparition de cette troisième faille ne signifie donc pas que les correctifs de PHP2Shell ont été contournés. Elle montre qu'une vulnérabilité distincte a été identifiée dans le même contexte de recherches intensives autour du traitement des requêtes par PHP.

24 octobre : une menace active, mais un impact encore difficile à mesurer

Au 24 octobre 2026, PHP2Shell fait l'objet d'une activité importante de reconnaissance et de tentatives d'exploitation sur Internet. Les preuves de concept sont publiques, tandis que les correctifs et plusieurs protections complémentaires sont désormais déployés.

L'ampleur réelle des compromissions reste cependant difficile à établir. Les millions de requêtes, scans et sondes observés ne correspondent pas au nombre de serveurs effectivement piratés et aucun élément ne permet à ce stade de conclure à une compromission généralisée de l'écosystème PHP.

26 octobre : la CISA confirme l'exploitation active des deux failles

Le 26 octobre 2026, la CISA ajoute CVE-2026-109618 et CVE-2026-109619 à son catalogue Known Exploited Vulnerabilities (KEV), réservé aux vulnérabilités pour lesquelles des éléments d'exploitation dans la nature ont été établis.

Cette inscription fait évoluer le statut de PHP2Shell. Jusqu'ici, les observations publiques établissaient principalement l'existence de scans, de millions de tentatives et d'une activité remontant au moins au 17 octobre. L'exploitation effective des vulnérabilités dans la nature est désormais reconnue officiellement.

Cela ne signifie toutefois pas qu'une compromission massive de l'écosystème PHP est démontrée. L'exploitation active est établie, mais le nombre de systèmes effectivement compromis et l'ampleur réelle de l'incident restent inconnus.

Ce que nous surveillons maintenant

Les principaux éléments à suivre sont désormais l'ampleur réelle des compromissions, l'identification de victimes dont l'accès initial peut être attribué avec suffisamment de certitude à PHP2Shell, l'évolution des charges malveillantes déployées après exploitation et l'éventuelle découverte d'un véritable contournement des correctifs de CVE-2026-109618 ou CVE-2026-109619.

Les investigations sur la période précédant la divulgation restent également importantes. D'autres compromissions ou tentatives antérieures au 21 octobre pourraient apparaître à mesure que les organisations réexaminent leurs journaux et leurs données de télémétrie.

Ce dossier sera mis à jour lorsque ces évolutions modifieront réellement l'état de la situation, plutôt qu'à chaque nouvelle tentative ou preuve de concept publiée.

Pour aller plus loin : données et suivi

Les incidents étudiés dans ce dossier s'inscrivent dans un environnement cyber plus large, dont certains indicateurs peuvent évoluer rapidement : nouvelles vulnérabilités exploitées, activité malveillante observée ou évolution du niveau d'exposition.

Ces données font l'objet d'un suivi séparé afin de distinguer les événements analysés dans ce dossier des tendances observables plus largement dans le temps.

Le Radar cyber permet ainsi de compléter cette analyse en suivant régulièrement plusieurs indicateurs issus de données publiques.

Consulter le Radar cyber →

Suivre les évolutions plus directement

Pour suivre plus directement les évolutions importantes, vous pouvez également retrouver L'Actu sans le Bruit sur Telegram. Le canal permet de suivre les nouveaux événements au fil de l'actualité, tandis que ce dossier n'est mis à jour que lorsque ces évolutions modifient réellement l'état de la situation.

Suivre L'Actu sans le Bruit sur Telegram