PHP2Shell : repérez l’exposition cachée de PHP et réduisez les risques applicatifs

Ne vous limitez pas aux serveurs web : examinez également les applications et les appliances, puis associez l’application de correctifs prioritaires à des contrôles WAF adaptés.

Ce qu’il faut retenir

• La mise à jour corrective de PHP est la seule solution complète contre PHP2Shell. D’autres mesures peuvent réduire l’exposition, mais elles ne remplacent pas le correctif.
• Ne vous limitez pas aux serveurs web évidents. L’exposition est plus large car de nombreuses appliances et applications intègrent du PHP sans le rendre visible.
• Établissez vos priorités en fonction de l’exposition, et non du client. Pour les équipes informatiques et les MSP, commencez par les systèmes PHP exposés à Internet, puis passez aux systèmes internes et aux appliances à mesure que les mises à jour des fournisseurs deviennent disponibles.

Trois vulnérabilités dans PHP ont transformé une simple question d’inventaire logiciel en une priorité de sécurité urgente : où PHP s’exécute-t-il exactement dans votre environnement ? Le 21 octobre 2026, le projet PHP a publié des correctifs pour CVE-2026-109618 et CVE-2026-109619, collectivement connus sous le nom de PHP2Shell. Deux jours plus tard, le 23 octobre, le projet a révélé une faille de désérialisation de session associée, CVE-2026-115560, qui exploite la même surface d’attaque et pour laquelle les mesures de protection décrites plus loin dans cet article s’appliquent à la clientèle de Barracuda. Ces vulnérabilités peuvent permettre l’exécution de code à distance sans authentification, et l’ avis de sécurité PHP rend la réponse sans équivoque : la mise à jour est le seul choix sûr.

Les pirates sont déjà à l’œuvre. Amazon Threat Intelligence a signalé des tentatives d’exploitation contre ses honeypots MadPot remontant au 17 octobre, soit quatre jours avant la divulgation publique. Amazon a précisé qu’il était difficile de savoir si ces premières tentatives auraient abouti sur des systèmes réels. En pratique, il faut donc privilégier les mesures correctives et enquêter sur les activités suspectes sans partir du principe que l’exposition a commencé le jour même de la publication des correctifs.

Ce qu'est PHP2Shell et pourquoi c'est important

PHP2Shell recouvre deux failles distinctes, toutes deux notées 9,2 (critique) sur l’échelle du Common Vulnerability Scoring System (CVSS) v4.0. Une faille de désérialisation liée à la session, CVE-2026-115560, a été révélée le 23 octobre 2026 dans le même chemin de progression du téléchargement de session et sera corrigée dans la prochaine version régulière de correctifs PHP. Les trois failles sont :

• CVE-2026-109618, exécution de code à distance par corruption en situation de manque de mémoire. Lorsque PHP manque de mémoire, son exécution peut être interrompue alors que les données internes de la requête ne sont que partiellement initialisées. Le nettoyage qui s’ensuit peut alors traiter ces données invalides comme si elles étaient valides.
• CVE-2026-109619, exécution de code à distance via un état global obsolète. Un état interne propre à une requête peut persister après la libération de sa mémoire. Une requête ultérieure traitée par le même processus worker peut utiliser cet état obsolète avant que PHP ne le réinitialise.
• CVE-2026-115560, exécution de code à distance via une attaque par désérialisation de session. Lors du téléchargement d’un fichier, la fonctionnalité de suivi de la progression du téléchargement de session de PHP écrit dans la session des valeurs fournies par les pirates sans les valider. Si l’application modifie le format de sérialisation de la session lors de l’exécution, PHP peut décoder ces valeurs en tant qu’objets actifs lors de la lecture suivante.

En clair, un pirate qui envoie la séquence adéquate de requêtes peut corrompre la mémoire du processus PHP et exécuter du code sous le compte du serveur web, sans avoir à s’authentifier. L’exploitabilité varie selon le déploiement. Le projet PHP estime que le risque est le plus élevé pour Apache avec mod_php, où un exploit démontré montre qu’une seule requête non authentifiée peut déclencher l’attaque avant même que le code de l’application ne soit exécuté. Ce détail a son importance : une application bien conçue et entièrement corrigée n’offre aucune protection si l’environnement d’exécution PHP sous-jacent est vulnérable.

Contrairement aux deux premières vulnérabilités, CVE-2026-115560 n’a pas été inclus dans les correctifs d’urgence du 21 octobre. PHP prévoit de corriger ce problème dans la prochaine version régulière de correctifs. Tant que cette version ne sera pas disponible et déployée, PHP recommande de conserver session.upload_progress.enabled=0.

Ce que les dirigeants doivent retenir : PHP2Shell est un problème d’exécution, pas un problème applicatif. Les revues de sécurité des applications et la qualité du code ne réduisent pas l’exposition ; seule la version de PHP le permet.

Quels systèmes sont exposés

Le projet PHP considère que toutes les installations PHP traitant des requêtes web sont exposées à un risque, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. Certaines distributions Linux et certains fournisseurs de support à long terme (LTS) proposent des correctifs rétroportés, et l’équipe de sécurité PHP a publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1 à l’intention des organisations qui compilent à partir du code source.

La question la plus délicate concerne les environnements d’exécution de PHP. La CERT-EU souligne que de nombreux produits commerciaux et open source utilisent PHP en arrière-plan et « pourraient également être affectés, même s’ils n’exposent pas directement une installation PHP ». Les systèmes de gestion de contenu, les portails clients, les consoles d’administration web et les appliances réseau ou de stockage peuvent tous intégrer PHP. Le National Cyber Security Centre (NCSC) du Royaume-Uni conseille aux organisations de ne pas limiter leur analyse aux versions obsolètes de PHP et de surveiller les fournisseurs tiers, « y compris pour les appliances et les services susceptibles d’intégrer PHP en tant que composant ». La CERT-EU et le NCSC renvoient tous deux à une liste des logiciels concernés publiée par le NCSC-NL.

Ce que les dirigeants doivent retenir : le premier livrable est une liste. Les systèmes exposés à Internet qui exécutent directement PHP, ainsi que tous les produits qui l’intègrent, dans cet ordre.

Appliquez d’abord les correctifs, puis utilisez des mesures provisoires comme solution de transition

Priorisez les systèmes accessibles depuis Internet, en particulier Apache avec mod_php, puis examinez les autres services PHP exposés et les installations internes. Pour la plupart des organisations, le moyen le plus rapide et le plus sûr consiste à utiliser le paquet de la distribution. Les distributions Linux et les fournisseurs LTS ont reçu les correctifs à l’avance ; les paquets mis à jour sont donc souvent disponibles avant qu’une équipe puisse compiler PHP à partir des sources. Après la mise à jour, chaque processus PHP doit être redémarré. Un serveur qui exécute toujours d’anciens processus PHP reste vulnérable. Les versions du 21 octobre couvrent les CVE-2026-109618 et CVE-2026-109619 ; le projet PHP prend en charge le CVE-2026-115560 dans sa prochaine version régulière de correction de bogues, le paramètre temporaire correspondant reste donc en place parallèlement à la mise à jour.

Les recommandations provisoires du projet PHP s’appliquent également, soit comme mesure transitoire pendant le déploiement des mises à jour (CVE-2026-109618 et CVE-2026-109619), soit comme mesure permanente jusqu’à la prochaine version de correction de bogues (CVE-2026-115560). Ces mesures ciblent des chemins d’attaque spécifiques ; elles ne rendent pas une installation sûre. Elles comprennent :

• Pour CVE-2026-109618 : définissez memory_limit=-1 de manière à ce que les applications ne puissent pas le modifier, fixez une valeur post_max_size faible (8 Mo pour les applications sans chargement de fichiers, 32 Mo lorsque des chargements sont nécessaires) et veillez à ce que upload_max_filesize reste inférieur à cette valeur.
• Pour CVE-2026-109619 : définissez session.upload_progress.enabled=0 et redémarrez chaque processus de travail. Sous PHP 8.5, définissez également fatal_error_backtraces=0. Ces paramètres doivent s’appliquer avant l’analyse de la requête ; par conséquent, la fonction ini_set() et les fichiers .user.ini de FPM ne sont d’aucune utilité.
• Pour CVE-2026-115560 : définissez session.upload_progress.enabled=0 et redémarrez chaque processus de travail. Veillez à ce que cette règle soit appliquée à un niveau que l’application ne puisse pas contourner (les fonctions ini_set() et les fichiers .user.ini de FPM ne sont d’aucune utilité), et laissez-la en place jusqu’à la prochaine version corrective de PHP.

Chacun de ces paramètres peut affecter une utilisation légitime, en particulier les téléversements de fichiers, et doit donc être testé. Ils devraient être accompagnés d’une échéance à laquelle la véritable mise à jour sera en place. Le NCSC va plus loin : si ni la mise à jour, ni les mesures d’atténuation ne peuvent être appliquées rapidement, les organisations devraient envisager de mettre le système hors ligne, et devraient rechercher des signes de compromission et des portes dérobées avant la mise à niveau.

Comment Barracuda contribue à atténuer la vulnérabilité PHP2Shell

L’avis de sécurité PHP recommande d’imposer des limites au niveau du serveur web ou du proxy concernant la taille des requêtes décodées, les champs de saisie, les parties multipart, les en-têtes et la profondeur d’imbrication, y compris pour les requêtes ne disposant pas d’un Content-Length utilisable. Un pare-feu d’application web (WAF) ou un proxy inverse peut aider à faire respecter ces limites avant que les requêtes n’atteignent l’environnement d’exécution vulnérable.

Barracuda Web Application Firewall et Barracuda WAF-as-a-Service, qui ne sont pas affectés par PHP2Shell, fournissent tous deux des contrôles de taille des requêtes qui peuvent contribuer à réduire l’exposition aux vecteurs d’attaque reposant sur des requêtes surdimensionnées, lorsqu’ils sont correctement configurés et appliqués en mode blocage. (Cela atténuera CVE-2026-109618.) Les équipes devraient vérifier les limites qui protègent chaque application reposant sur PHP et tester leur effet sur le trafic légitime. Ces contrôles ne doivent pas être considérés comme une mesure d’atténuation complète pour les deux vulnérabilités.  

• Pour CVE-2026-109618 (chemin de requête surdimensionnée) : Barracuda a vérifié que la politique de gestion des requêtes par défaut bloque l’exploitation des requêtes surdimensionnées pour la vulnérabilité CVE-2026-109618 lorsque le service fonctionne en mode blocage.
• Pour CVE-2026-109619 (chemin de progression du chargement de session) : Barracuda a publié des protections conçues pour réduire l’exposition aux attaques ciblant le chemin de progression du chargement de session. Ces protections sont automatiquement appliquées à toutes les applications Barracuda WAF-as-a-Service, tandis que les clients Barracuda Web Application Firewall peuvent les activer en suivant les instructions de configuration supplémentaires fournies par Barracuda. Des tests complémentaires de validation et de couverture sont en cours.
• Concernant la vulnérabilité CVE-2026-115560 (chemin de désérialisation de session) : les mesures de protection existantes liées à PHP_SESSION_UPLOAD_PROGRESS pour la vulnérabilité CVE-2026-109619 s’appliquent également à cette vulnérabilité. Barracuda a testé les exploits de preuve de concept disponibles et a confirmé qu’ils sont bloqués à l’aide de la même approche ; par conséquent, aucune mesure d’atténuation WAF distincte n’est actuellement requise. Nous recommandons à notre clientèle de continuer à suivre les recommandations de PHP et d’appliquer la future version corrective dès qu’elle sera disponible.

Le mode compte : un WAF en mode surveillance ou passif enregistre le trafic, mais ne le bloque pas. Vérifiez que la protection est bien appliquée, plutôt que de supposer qu'une règle configurée protège activement une application. Maintenez la mise à jour PHP au cœur de la réponse. 

Pour CVE-2026-109619 et CVE-2026-115560 (chemins de progression du téléversement de session) : Barracuda WAF-as-a-Service applique automatiquement une protection contre les schémas d’exploitation connus impliquant PHP_SESSION_UPLOAD_PROGRESS. Les clients et les partenaires de Barracuda Web Application Firewall doivent appliquer la politique supplémentaire décrite dans cet article de Barracuda Campus. Barracuda a testé les scénarios de preuve de concept actuellement disponibles pour CVE-2026-115560 et confirmé que la même protection s’applique. Aucune mesure d’atténuation distincte du WAF n’est actuellement requise pour CVE-2026-115560.

L’équipe Barracuda maintient une veille active, et les recherches visant à identifier d’éventuels vecteurs d’attaque supplémentaires ou des mutations susceptibles d’exploiter ces vulnérabilités se poursuivent. 

Pourquoi les équipes réduites et les fournisseurs de services managés (MSP) font face à une pression accrue

Pour les organisations qui ne disposent pas d’une équipe dédiée à la gestion des vulnérabilités, PHP2Shell constitue une tâche urgente supplémentaire qui vient s’ajouter au travail habituel. L’étape d’inventaire est souvent la plus difficile, car le PHP intégré à un produit tiers n’apparaît pas dans la liste des paquets installés. Les MSP sont confrontés au même problème, qui se multiplie dans les environnements de leurs clients, souvent avec des configurations d’hébergement, des versions de PHP et des fenêtres de changement différentes pour chacun.

Une approche pratique consiste à effectuer un triage en fonction du niveau d’exposition plutôt que par client : en priorité les systèmes exposés à Internet utilisant mod_php, puis les autres systèmes PHP exposés à Internet, et enfin les systèmes internes et les appliances à mesure que les mises à jour des fournisseurs sont disponibles. Un message concis et cohérent adressé aux clients, précisant ce qui a été corrigé, ce qui est en attente d’une mise à jour du fournisseur et ce qui est protégé par des mesures provisoires, peut éviter une grande partie du travail de suivi.

Votre checklist de réponse à php2shell 

PHP2Shell est un événement à fenêtre courte : les correctifs existent et les détails sont publics. Les priorités de cette semaine sont :

1. Dressez l’inventaire. Répertoriez tous les systèmes exécutant PHP, en commençant par ceux exposés à Internet, et incluez les appliances et les produits intégrant PHP.
2. Mettez à jour vers une version corrigée. Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 en utilisant si possible des paquets de distribution ou LTS, puis redémarrez chaque worker. Pour le CVE -2026-115560, surveillez la prochaine version régulière de correctifs de PHP.
3. Planifiez la fin de vie des versions. Pour PHP 8.1 et les versions antérieures, utilisez un rétroportage du fournisseur ou les rétroportages du code source de PHP à titre de solution provisoire, et planifiez la migration vers une branche prise en charge.
4. Appliquez des mesures provisoires lorsque l’installation des correctifs doit être différée. Désactivez session.upload_progress.enabled pour CVE-2026-109619 et CVE-2026-115560. Utilisez les paramètres du projet PHP, testez leur impact sur les téléversements, et fixez une échéance pour la véritable mise à jour.
5. Vérifiez la couche web. Confirmez que le WAF ou le proxy situé devant chaque application PHP fonctionne en mode blocage et applique des limites de taille des requêtes.
6. Recherchez les signes de compromission. Pour les systèmes qui sont restés exposés après le 21 octobre, examinez les journaux du serveur web et des workers PHP afin de détecter les plantages et les processus inattendus avant de clôturer le ticket.