La protection proactive de Fastly contre PHP2Shell, les vulnérabilités critiques PHP RCE CVE-2026-109618 et CVE-2026-109619

PHP, la durée d’exécution sur laquelle reposent la plupart des systèmes de gestion de contenu, des plateformes d’e-commerce et des infrastructures de publication du Web, est rattrapé par les fantômes du passé : un choix de conception fait il y a plusieurs décennies, à l’origine d’une faille dans la gestion des erreurs fatales par son moteur. Les vulnérabilités divulguées aujourd’hui, baptisées php2shell, ont toutes pour origine ce choix de conception, que nous examinerons dans cet article.

La PHP Foundation a attribué deux identifiants CVE (CVE-2026-109618, CVE-2026-109619), et les vulnérabilités correspondantes sont corrigées à partir de PHP 8.2 (versions corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35). PHP a également publié des correctifs pour les versions 7.4, 8.0 et 8.1, destinés à l'intégration par les distributeurs de paquets. Les versions antérieures à 7.4 ne recevront pas de correctif de PHP ; leur correction sera laissée à la discrétion des distributeurs de formules. Toutes les versions de PHP encore maintenues sont affectées. À ce jour, le plus ancien chemin d’exploitation démontré existe depuis 2012. 

Des éléments attestent que des attaques étaient déjà en cours avant la divulgation ; il ne s’agit pas de problèmes théoriques.

Nous encourageons vivement les clients à rechercher dans leur environnement tous les serveurs d’application utilisant mod_php ou php-fpm, et à appliquer les correctifs sans tarder. Si vous ne trouvez aucun moyen d’appliquer un correctif, nous recommandons une atténuation active. 

À ce stade, compte tenu de la nature de ces techniques pour exploiter (notamment l’ exécution de code à distance avant authentification (RCE)), vous devez partir du principe qu’une atténuation active n’offrira qu’une protection "partial" et pourrait nécessiter de bloquer une part importante du trafic légitime, selon l’approche adoptée.

Nous sommes reconnaissants de l’étroite collaboration avec OpenAI, ainsi qu’avec les autres partenaires de l’écosystème logiciel qui ont contribué à cet effort urgent visant à protéger autant d’organisations que possible. 

Dans cet article, nous présenterons plus en détail ces vulnérabilités, expliquerons comment ces exploiter PHP pourraient affecter votre entreprise, et proposerons des conseils pour atténuer les tentatives d’exploitation.

L’essentiel sur les CVE-2026-109618 & CVE-2026-109619

Lorsque PHP atteint une limite de mémoire, dépasse le délai d’exécution ou perd la connexion, il n’interrompt pas proprement son exécution. Il abandonne l’opération en cours et passe directement à un point de reprise, laissant derrière lui un état interne partiellement modifié. Cet état résiduel peut faire référence à de la mémoire déjà libérée ou contenir des structures de données qui n’ont jamais été entièrement finir de créer.

Des chercheurs ont montré qu’un hacker peut déclencher ces conditions d’erreur au moyen d’une seule requête HTTP non authentifiée. Le hacker peut réussir sans connexion, sans point de terminaison particulier, ni coopération de l’application. La RCE permet au hacker de contrôler suffisamment précisément ce qui subsiste dans l’état résiduel pour amener PHP à exécuter des commandes shell arbitraires sous l’identité de l’utilisateur du système d’exploitation prétendument légitime du serveur web. Le processus de travail reste actif et continue ensuite de traiter des requêtes, sans se douter qu’il a désormais un nouveau maître.

La seule entrée du Log est une erreur courante de mémoire insuffisante. La suite s’annonce pour le moins mouvementée.

On ne saurait surestimer l’impact potentiel:

• Portée : toute organisation disposant d’applications PHP

• Profondeur : le hacker peut faire ce qu’il veut dans l’application

Comme vous pouvez utiliser une configuration PHP comportant, sans que vous le sachiez, mod_php ou php-fpm, nous encourageons vivement les clients à considérer toute application PHP comme potentiellement vulnérable et à analyser leur environnement en conséquence.

Un point rassurant : pour qu’une attaque aboutisse à l’exécution de code sur x86_64, les preuves de concept existantes nécessitent de connaître le binaire PHP précis en cours d’exécution ainsi que l’organisation de l’espace d’adressage du serveur. La plupart des déploiements pourraient donc être « à l’abri » d’une exécution de code à distance (RCE). Ne présumez pas que c’est votre cas. Si vous exploitez une application PHP 32 bits, vous devriez probablement partir du principe qu’elle est compromise. 

Analyse approfondie : un problème de conception au niveau du moteur

Le moteur de PHP gère les erreurs fatales d’une manière originale. Si les choses tournent très mal, les fonctions en cours d’exécution ne reçoivent aucune notification et n’ont aucune possibilité de réparer les dégâts qu’elles ont causés. Leur travail inachevé reste exactement en l’état. Plus précisément, le moteur utilise un mécanisme appelé longjmp(), qui propulse directement l’exécution vers un point de reprise (comme si l’on attrapait l’application par la peau du cou, pour ainsi dire), plutôt que d’effectuer le logging d’une erreur et de quitter immédiatement la scène.

Le moteur de PHP déclenche ce mécanisme, appelé zend_bailout, depuis chaque chemin d’exécution qui applique une limite de ressources ou gère une condition fatale (et ces chemins sont nombreux). Lorsque l’application subit un épuisement de la mémoire, un dépassement du temps d’exécution, une interruption de la connexion client ou une erreur fatale non interceptée, tous ces cas sont traités par zend_bailout.

Cette approche créative serait gérable si elle était rare ou si elle survenait dans des circonstances sous contrôle. Comme le sait bien quiconque a assez d’expérience pour avoir connu les joies du développement PHP, ces erreurs fatales se produisent régulièrement dans les déploiements PHP en production et, surtout, ces conditions séduisent les hackers qui rêveraient d’exercer un contrôle total sur le Web (c’est-à-dire tous les serveurs d’application qui exécutent PHP aujourd’hui).

Qu’est-ce qui conduit à l’exploitation ?

Lorsque zend_bailout se déclenche, toute opération interne de PHP interrompue en cours de modification d’une structure de données laisse cette structure dans un état incohérent, qui ne correspond pas à l’état attendu par l’opération. Le code de nettoyage de PHP, exécuté ensuite après chaque requête pour libérer l’état de la requête, rencontre alors ces données incohérentes et les traite comme si elles étaient valides.

Les preuves de concept publiées doivent être considérées comme de simples exemples illustratifs : elles sont loin de recenser tous les chemins d’abandon et de sortie anticipée susceptibles de déclencher des conditions similaires que les hackers peuvent exploiter. Pour mieux comprendre pourquoi cela pose problème pour Internet : l’arborescence du code source de PHP fait appel au mécanisme zend_bailout à de nombreux endroits ; chaque appel peut interrompre un ensemble différent d’opérations en cours, et chacun présente ses propres invariants en cas d’interruption.

Le nombre de combinaisons possibles est, pour le dire avec modération, explosif. Corriger les chemins précis mis en évidence par les chercheurs ne rend pas le mécanisme sûr. Compte tenu du retour sur investissement de cette vulnérabilité, les hackers seront très motivés pour trouver le prochain chemin encore inconnu et poursuivre leur série d’attaques exploitant cette faille.

Partez du principe que les organisations cybercriminelles, tout comme les États-nations, vont s’en emparer : cette primitive est puissante lorsqu’elle est combinée à une fuite d’informations… et cette fuite n’a même pas besoin d’être particulièrement sophistiquée. Le bogue à l’origine de la fuite d’informations peut faire planter le processus et être tout de même considéré comme valide grâce à l’architecture prefork de mod_php. La question de savoir « comment paniquer en toute sécurité » sera abordée une autre fois.

Pourquoi l’impact est-il si important ?

Voici ce qu’un hacker pourrait obtenir en parvenant à exécuter du code à distance sur un serveur PHP :

• Mettre hors service des sites web et des applications basés sur PHP avec une seule requête non authentifiée ; à l’échelle, cela se traduit par une interruption de service prolongée (si le contenu n’est pas mis en cache)

• Exécutez n’importe quelle commande sur le serveur sans perturbation visible ; le serveur accepte volontiers les données envoyées par les hackers

• Voler tous les identifiants utilisés par l’application : mots de passe de bases de données, clés API, clés de fournisseurs cloud et clés de chiffrement

• Accéder aux bases de données, aux systèmes de cache, aux files de messages et aux systèmes internes protégés par ces identifiants : dossiers clients, transactions, informations personnelles identifiables, tout ce avec quoi l’application communique ; cela peut entraîner des obligations de notification des failles et d’autres obligations réglementaires

• Pénétrer plus profondément dans le réseau : parcourir l’infrastructure cloud, accéder aux jetons de comptes de service Kubernetes, à Envoy, aux clés SSH stockées sur disque et aux services internes, puisque le serveur web se trouve déjà dans votre environnement de confiance

• Établir un accès persistant qui résiste aux redémarrages et aux redéploiements du serveur (l’équivalent d’un transat confortable pour le hacker, sous la forme de portes dérobées dans des fichiers php ou de tâches planifiées discrètes)

• Aucun indice évident : la seule entrée du Log est une erreur de mémoire courante que les équipes des Opérations voient régulièrement et examinent rarement (sauf si des SRE sont exceptionnellement curieux)

L’enchaînement des conséquences peut être grave dans divers cas d’utilisation. Prenons l’exemple d’une boutique en ligne classique : une requête HTTP → compromission du serveur → installation d’un dispositif persistant de vol des données de cartes → vol massif et continu de données de cartes concernant l’ensemble des clients → faille de la Payment Card Industry Data Security Standard (Norme de sécurité des données de l'industrie des cartes de paiement, PCI DSS) → perte potentielle de toute capacité à traiter les paiements par carte.

Comment déterminer si vous êtes exposé

Nous invitons nos clients à considérer toute application PHP comme potentiellement vulnérable et à auditer leur environnement de production en conséquence. Ce n’est pas le moment de bâcler l’analyse des vulnérabilités ; commencez l’inventaire dès maintenant. Pour déterminer plus précisément l’exposition, vérifiez les critères suivants :

• PHP derrière Apache avec mod_php en mode prefork

• Un rapport memory_limit / post_max_size qui permet à un hacker de provoquer une situation OOM à partir du corps d’une requête POST

• Les variantes de déni de service (Déni de service), qui provoquent des plantages sans exécution de code, touchent un plus large éventail de configurations, notamment php-fpm

Les secteurs qui, selon nous, pourraient être particulièrement vulnérables à ces attaques sont notamment les suivants :

• E-commerce (plateformes de commerce en ligne) | post_max_size est souvent supérieur à la valeur par défaut pour permettre l’envoi de fichiers

• Médias & édition (systèmes de gestion de contenu) | vaste surface constituée d’instances Apache standard utilisant mod_php, avec des configurations par défaut (ou presque)

• Éducation (plateformes d’apprentissage, portails étudiants personnalisés, outils destinés au corps enseignant) | PHP est très présent dans l’enseignement supérieur, où sa gestion repose souvent sur des équipes réduites

• Hôtellerie et voyages (moteurs de réservation, plateformes de fidélisation, systèmes de gestion hôtelière) | Les configurations PHP personnalisées sur des piles LAMP présentent souvent des limites de téléversement élevées pour les photos et les documents

• Services financiers (intégrations de paiement, portails de demande de prêt, demandes d’indemnisation) | valeur élevée de post_max_size compte tenu des nombreux flux de travail impliquant des documents ; PHP est le COBOL des applications destinées aux clients

• Logiciel en tant que service (outils d’administration internes, tableaux de bord du support client, frameworks web) | souvent moins surveillés et gérés par des équipes réduites de PME

• Fournisseurs d’hébergement infogéré et d’hébergement mutualisé (panneaux de contrôle d’hébergement Web, environnements Apache multi-client) | impact démultiplié si une configuration PHP vulnérable touche un serveur partagé

• Secteur de la santé (portails patients, systèmes de prise de rendez-vous, intégrations de données de santé) | les téléversements de documents sensibles, tels que les résultats d’analyses, les formulaires d’orientation et les cartes d’assurance, nécessitent une valeur de post_max_size plus élevée

Comment bénéficier d'une protection active dès maintenant

Pour atténuer les risques pesant sur leurs applications protégées par NGWAF, les clients de Fastly peuvent activer le signal couvrant à la fois CVE-2026-109618 & CVE-2026-109619. Le contenu de détection de cette règle modélisée spécifique aux CVE recherche les caractéristiques structurelles de ces tentatives d’exploitation — des corps et des paramètres dont la structure diffère de celle du trafic légitime — qui peuvent indiquer de possibles tentatives d’exploitation des CVE php2shell.

L’équipe de recherche dans le domaine de la sécurité de Fastly a développé et testé ce contenu en étroite collaboration avec OpenAI et des partenaires de la communauté ; nous leur sommes reconnaissants de ce partenariat. Notre équipe de recherche dans le domaine de la sécurité mettra à jour le correctif virtuel selon les besoins ; toute personne ayant choisi d’en bénéficier recevra automatiquement les mises à jour ultérieures. 

Fastly continuera d’étudier les couches de protection supplémentaires que nous pouvons proposer à nos clients pour détecter et bloquer le trafic d’attaque lié à php2shell. Nous continuerons à développer et à affiner le contenu pertinent du NGWAF à mesure que nous observerons des tentatives d’exploitation.

Signaux et indices à examiner en priorité

Pour atténuer le bug plus simple lié à la progression des téléversements, assurez-vous que session.upload_progress.enabled = Off est défini dans php.ini. 

Pour la vulnérabilité zend_bailout, plus grave, les principales caractéristiques relevées à ce jour dans le trafic lié à exploiter et aux preuves de concept sont les suivantes :

Réduire la surface d’attaque grâce à la configuration PHP

• post_max_size = 8M — maintient la taille des corps des requêtes POST sous le seuil nécessaire pour provoquer un épuisement de la mémoire avec une seule requête. Effectuez des tests sur tout flux de travail qui accepte le téléversement de fichiers ou l’envoi de formulaires volumineux ; 8M est la valeur par défaut de PHP, mais elle a été augmentée dans de nombreux déploiements en production.

• max_input_nesting_level = 4 : limite les noms de variables fortement imbriqués, utilisés dans la charge utile servant à exploiter la table de hachage. Portez cette valeur à 6 si l’application utilise des structures de formulaires imbriquées complexes. Testez l’envoi des formulaires dont les noms de champs utilisent la notation de tableau.

• session.upload_progress.enabled = 0 : désactive la fonctionnalité de suivi de la progression des téléversements qui déclenche les chemins pour exploiter liés aux sessions. N’affecte que les applications qui affichent des barres de progression des téléversements en temps réel à l’aide du mécanisme de session intégré à PHP. La plupart des applications qui affichent la progression des téléversements utilisent plutôt des approches basées sur JavaScript.

Dans le trafic HTTP (inspection par WAF, par proxy ou du réseau)

• Envois de formulaires anormalement volumineux. Corps de requêtes POST au format application/x-www-form-urlencoded dépassant 1 à 2 Mo. Les envois de formulaires légitimes font presque toujours moins de 100 Ko. Les formulaires encodés pour URL de plusieurs mégaoctets sont suffisamment rares pour justifier une investigation sur tout point de terminaison exécutant PHP.

• Noms de champs vides avec une imbrication profonde. Corps de requêtes POST commençant par = (un champ sans nom), suivi d’un nom de champ contenant des crochets ouvrants [ répétés. C’est la forme précise de la charge utile utilisée pour exploiter la table de hachage.

• Noms des champs de suivi de la progression des envois. Envois de fichiers multipart contenant un champ nommé PHP_SESSION_UPLOAD_PROGRESS. Il s’agit d’une fonctionnalité légitime de PHP, mais elle déclenche également les chemins d’exploiter liés aux sessions. Signalez ce champ pour examen sur les points de terminaison qui n’utilisent pas le suivi de la progression des envois.

Dans les fichiers Log d’erreurs de l’application et du serveur web

• Erreurs OOM provenant du fonctionnement interne de PHP, et non du code de l’application. Recherchez le message Allowed memory size ... exhausted, avec l’emplacement indiqué comme Unknown à la ligne 0. Le fichier Unknown et la ligne 0 indiquent que l’erreur s’est produite lors de l’analyse de la requête par PHP lui-même, avant l’exécution de tout script d’application. Une erreur OOM provenant du code de l’application indiquerait un fichier et un numéro de ligne réels.

• Rafales d’erreurs de segmentation. Groupes d’entrées Apache AH00052 ... exit signal Segmentation fault (11) sur une courte période. Quelques erreurs de segmentation isolées ne sont pas inhabituelles ; des dizaines en quelques minutes, suivies d’une seule réponse HTTP 200 lente, correspondent à la phase de exploiter où l’adresse est récupérée par force brute.

Dans la surveillance des processus (au niveau de l’hôte)

• Des processus de travail Apache/PHP lancent des processus shell. Tout processus de travail mod_php exécutant /bin/sh -c ... en tant que processus enfant. En opération normale, les processus de travail mod_php ne lancent jamais de processus enfants, sauf si l’application PHP appelle explicitement une fonction d’exécution de commandes (exec, system, shell_exec, etc.). Si aucun code de l’application n’a été exécuté (ce qui est le cas avec les exploiter connus à ce jour), considérez qu’un shell lancé par un processus de travail PHP correspond au déclenchement de la charge utile d’exécution de code.

Pour les déploiements PHP-FPM

• pm.max_requests = 50 : force les processus de travail à redémarrer après 50 requêtes, ce qui limite la période pendant laquelle une corruption entre requêtes (liée aux bogues de session et de conversion des données) peut être exploitée. N’empêche pas l’exploitation du bogue de la table de hachage, qui exploite une corruption au sein d’une seule requête. Une valeur de 1 empêcherait totalement les attaques entre requêtes, mais au prix d’une forte dégradation des performances.

À venir

Nous sommes conscients que nos clients nous confient la résilience de leurs services essentiels à leur activité, et notre mission principale est de vous soutenir lorsque des incidents tels que ceux liés aux vulnérabilités CVE-2026-109618 et CVE-2026-109619 surviennent. Nos équipes sont à votre disposition pour vous aider à gérer l’atténuation continue de php2shell, que vous soyez un client de longue date de la plateforme Fastly ou un nouveau client ayant besoin d’une protection immédiate. Faites-nous savoir comment nous pouvons vous aider.

Pour résumer :

• Le mécanisme utilisé pour mener ces attaques, dans lequel zend_bailout appelle longjmp() pour abandonner les opérations en cours, est présent dans l’ensemble du code de base et accessible depuis le trafic HTTP ordinaire. 

• Appliquez rapidement les correctifs, et gardez à l’esprit qu’ils ne couvrent que les bogues découverts et exploités à ce jour. 

• Attendez-vous à voir apparaître des attaques réelles et de nouvelles variantes au moins cette semaine et la semaine prochaine. 

• La condition architecturale qui les a rendues possibles est une propriété fondamentale de la conception de la gestion des erreurs du moteur, et non un « défaut » localisé dans le code ; elle persistera après la publication de ces correctifs.

Nous sommes heureux d’apporter notre contribution à cet effort collectif visant à protéger Internet dans son ensemble. Nous nous engageons à poursuivre notre collaboration à mesure que les attaques se développent ; nous voulons que nos clients et l’ensemble de l’écosystème logiciel puissent réagir rapidement tout en restant protégés. 

Dans un esprit visant à préserver la résilience de l’Internet et la collaboration au sein de l’écosystème, Fastly surveillera de manière proactive son réseau mondial afin de détecter toute tentative d’exploitation de php2shell et publiera des mises à jour régulières sur les activités observées, à l’instar des informations que nous avons publiées lors des incidents React2Shell et Log4Shell. Si vous avez besoin d’aide, n’hésitez pas à nous contacter. Nous vous tiendrons informés.