Les correctifs php2shell sont désormais disponibles pour les versions de PHP allant de la 5.2 à la 8.1

Principaux enseignements

• « php2shell » est le nom donné à deux failles critiques de type RCE (exécution de code à distance) affectant le cœur de PHP, à savoir CVE-2026-109618 et CVE-2026-109619.
• PHP les a corrigées dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, mais les branches en fin de vie ne bénéficient d'aucun correctif en amont.
• Des tentatives d'attaque ont été signalées avant la publication de cette mise à jour ; veuillez donc appliquer le correctif dès maintenant et redémarrer tous les processus PHP.
• Le service « Endless Lifecycle Support » (ELS) de TuxCare dédié aux environnements d'exécution propose désormais des versions stabilisées pour les versions de PHP arrivées en fin de vie.

En bref

Aller directement à la version longue ↓

De quoi s'agit-il ? « php2shell » est le surnom donné par les chercheurs aux vulnérabilités CVE-2026-109618 et CVE-2026-109619, deux failles critiques permettant l'exécution de code à distance dans PHP lui-même, et non dans un framework ou un CMS. La nouvelle a fuité le 20 octobre 2026, avant la date de divulgation prévue, et l'équipe de sécurité de PHP a avancé la publication de son correctif d'urgence au 21 octobre.

Impact : ces deux vulnérabilités permettent à un attaquant non authentifié d'exécuter du code en tant qu'utilisateur du processus PHP ; toutefois, la facilité d'exploitation d'un serveur donné dépend de la manière dont PHP y est exécuté. PHP a confirmé l'existence d'une vulnérabilité permettant une exécution de code à distance (RCE) complète contre Apache mod_php avec les limites par défaut, et a également validé une voie d'exploitation contre PHP-FPM. Aller à cette section →

Gravité : L'équipe de sécurité de PHP attribue à ces deux failles une note de 9,2 selon le CVSS v4.0, ce qui correspond à un niveau « critique ». La note de 10,0 qui a circulé lors de la fuite n'a jamais été celle attribuée par PHP. Aller à cette section →

Qui est concerné : les avis de sécurité de PHP couvrent les versions concernées dans les quatre branches prises en charge, tandis que l'outil d'exploitation qui a fuité prétend fonctionner jusqu'à la version 5.4.0. Le développeur en amont ne propose de correctifs que pour les versions 8.2 à 8.5 ; par conséquent, PHP 8.1, 8.0, 7.x et 5.x ne bénéficient d’aucun correctif sur php.net, et Mallory a recensé environ 884 000 serveurs exposés à Internet fonctionnant sous l’une de ces versions. Aller à cette section →

Situation : Dane Knecht, directeur technique de Cloudflare, a signalé de premières tentatives d’attaque contre des sites PHP à 07 h 43 UTC le 21 octobre, quelques heures avant la publication du correctif ; on ignore toutefois combien d’entre elles ont abouti. Des versions « Endless Lifecycle Support » (ELS) de Runtimes corrigeant ces deux vulnérabilités (CVE) sont désormais disponibles pour toutes les branches en fin de vie, de PHP 5.2 à 8.1.

Procédez ainsi dès maintenant : identifiez toutes vos installations PHP, y compris celles intégrées aux logiciels de fournisseurs et aux panneaux de contrôle, et commencez par toutes celles qui utilisent Apache mod_php, sans oublier les hôtes FPM. Mettez à jour les branches prises en charge à partir de la source ou de votre distribution, et transférez celles qui sont en fin de vie vers une version ELS stable ou retirez-les de l’Internet public. Redémarrez ou remplacez ensuite chaque processus PHP, car l’ancien code continue de traiter les requêtes jusqu’à ce que ce processus soit arrêté. Pour voir ce qui est réellement en cours d’exécution :

ps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[h]ttpd|[a]pache2'

Au fur et à mesure que vous parcourez la liste, surveillez les processus PHP « worker » qui lancent des shells ou des outils de téléchargement. C'est généralement ainsi que se manifestent les attaques.

Aller à cette section →

La plupart des urgences PHP trouvent leur origine dans une application. Un plugin WordPress, une extension Magento, un package Laravel que personne n'a touché depuis 2019. Vous le mettez à jour, vous modifiez quelques clés de sécurité, puis vous passez à autre chose. Rien de tout cela n'affecte l'interpréteur sous-jacent.

php2shell ne fonctionne pas ainsi. Les vulnérabilités se trouvent dans l’interpréteur ; par conséquent, les logiciels concernés sont en gros « tout ce qui exécute PHP », et le correctif n’est disponible que sur quatre branches maintenues. Tous ceux qui utilisent encore PHP 7.4 dans le cadre d’une application de facturation héritée (et ils sont nombreux) ont découvert l’existence d’une faille RCE critique pour laquelle aucun correctif en amont n’est prévu, jamais.

Il y a également un troisième aspect à prendre en compte. Ces failles ont d’abord fait l’objet de rumeurs avant d’être rendues publiques sous forme de correctifs, et les pirates ont commencé à les exploiter avant même que les correctifs ne soient disponibles.

Le score CVSS 4.0 actuel attribué par le NIST est de 9,2 (Critique), mais d’autres chiffres non confirmés circulaient. Le matin du 20 octobre, un message publié sur Hacker News affirmait que deux failles PHP permettant l’exécution de code à distance, notées 10,0 et remontant à PHP 5, seraient révélées le jeudi 22 octobre. L’auteur du message n’a fourni aucune preuve, si ce n’est « source : fais-moi confiance, mec ». Le message a été supprimé, mais des captures d'écran avaient déjà été largement diffusées.

Cette rumeur n'a pas cessé de circuler, car watchTowr a publié un message confirmant que l'information était vraie, que les failles faisaient l'objet d'un embargo et que tout le monde devait attendre jusqu'à jeudi. À 19 h 33 UTC ce soir-là, Jakub Zelenka a envoyé l’avis préalable de l’équipe de sécurité PHP à la liste php.announce. Celui-ci confirmait deux vulnérabilités critiques, toutes deux notées 9,2 selon le CVSS v4.0, avec une publication prévue le lendemain, le 21 octobre, et se réservait le droit de les publier plus tôt si des détails venaient à être rendus publics ou si des exploits apparaissaient.

L'embargo a pris un jour de retard, et de nombreuses autres personnes consultaient les mêmes captures d'écran. À 07 h 43 UTC le lendemain matin, le directeur technique de Cloudflare a déclaré que l'entreprise constatait l'émergence des premières attaques, et que ses règles WAF provisoires avaient été déployées sur tous les forfaits, y compris le forfait Gratuit.

À noter d'ailleurs que l'avis préalable de PHP ne mentionnait aucun de ces deux CVE. Ces identifiants ont d'abord circulé via les documents divulgués et les articles de WatchTower, puis les avis de sécurité de PHP les ont confirmés lors de la publication des correctifs.

Avant la publication, on disposait de peu d’informations. watchTowr a déclaré penser avoir reproduit la vulnérabilité CVE-2026-109618, Huntress n’avait pas élaboré de preuve de concept, et selon Sansec, la capture d’écran de PHP2Shell qui avait fuité montrait une bannière affirmant que toutes les versions à partir de la 5.4.0 étaient concernées. Les deux avis de sécurité publiés par PHP le 21 octobre ont comblé la plupart des lacunes.

109618, « RCE via une corruption OOM », tient à la manière dont PHP gère les erreurs de mémoire insuffisante. Il utilise longjmp() pour interrompre la requête ; si une allocation échoue alors que la mémoire de la requête n'est que partiellement initialisée, le code d'arrêt détecte ensuite cet état d'erreur et réagit en conséquence. L'analyse en plusieurs parties offre aux attaquants plusieurs moyens de provoquer un OOM tout en restant dans les limites apparentes, par exemple en utilisant des parties comportant un nombre illimité d'en-têtes. Sur mod_php, tout cela se produit lors du démarrage de la requête, avant même que le code de l'application ne soit exécuté.

CVE-2026-109619, « RCE via un état global périmé », est une vulnérabilité de type « use-after-free » qui s'étend sur plusieurs requêtes. Une erreur fatale, y compris un OOM, peut laisser un worker persistant détenir des pointeurs vers de la mémoire ayant appartenu à une requête déjà terminée. Une requête ultérieure sur ce même worker accède alors à cet état obsolète avant que l’initialisation normale ne le réinitialise. Bien que plus difficile à exploiter, PHP a tout de même confirmé l’existence d’une vulnérabilité RCE contre mod_php et validé le chemin de session contre PHP-FPM.

La manière dont vous exécutez PHP a donc son importance. mod_php représente le pire scénario dans les deux cas. FPM tue un processus enfant lorsque le démarrage d’une requête échoue, ce qui bloque la séquence OOM la plus propre, mais PHP continue de le considérer comme vulnérable. PHP appelle « FrankenPHP », qui est probablement vulnérable aux attaques OOM indépendantes de l’application, tout comme mod_php, tandis que LSAPI se comporte davantage comme FPM.

La connexion « Progression du téléchargement »

Cette mention « 5.4.0 » s'est avérée être un indice précieux. PHP 5.4 a introduit la fonctionnalité de suivi de la progression des téléchargements en session, qui permet à un script de vérifier l’avancement d’un téléchargement en plusieurs parties. Elle est activée par défaut, et la note d’information de PHP la décrit comme très peu utilisée. Elle est également identifiée comme une vulnérabilité confirmée dans CVE-2026-109619, car elle accède à la gestion des sessions avant l’initialisation normale et peut récupérer l’état laissé par une requête interrompue, non session_start() Un appel est nécessaire. L'analyse d'un chercheur avait signalé une vulnérabilité de type « use-after-free » dans ce chemin d'exécution avant même la publication des avis de sécurité, et il n'était pas loin de la vérité.

La désactivation de cette fonctionnalité ne constitue toujours pas une solution. Gina Banyard, membre de l'équipe principale de PHP, a déclaré dès le début que l'application d'un correctif était la seule mesure d'atténuation possible, et les deux avis de sécurité viennent étayer ses propos, en indiquant qu'une mise à jour est la seule solution complète et fiable. La désactivation de l'affichage de la progression du téléchargement bloque le chemin d'attaque par session démontré, mais aucun des autres chemins du cycle de vie.

Si certains serveurs ne peuvent pas être mis à jour aujourd'hui, la solution provisoire de PHP pour ce chemin d'accès sera mise en place php.ini ou passez nous voir à conf.d, et Sansec y ajoute en plus un mode de session strict :

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Les pools FPM peuvent remplacer les paramètres INI principaux ; vérifiez donc la configuration effective de chaque pool. Si un pool nécessite ses propres paramètres de remplacement, utilisez-les, puis redémarrez ses workers :

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Le mode « session stricte » est une fonctionnalité propre à PHP. consignes relatives à la sécurité des sessions est préconisé depuis des années, de sorte que la première solution ne coûte pratiquement rien, même si Redis ou les gestionnaires de sessions de bases de données peuvent ne pas implémenter la vérification d'identifiant sur laquelle elle repose. Parmi les autres solutions provisoires, on peut citer fatal_error_backtraces=0 sous PHP 8.5 et en bloquant les requêtes multipart au niveau du front-end si l'application n'accepte jamais de fichiers en téléchargement. Concernant la vulnérabilité CVE-2026-109618, la principale mesure de contournement dans la configuration de PHP consiste à appliquer memory_limit=-1 au niveau administratif et en redémarrant chaque processus de travail, ce qui supprime la limite prévisible par requête sur laquelle repose la faille confirmée. Procédez avec prudence, car cela désactive également la protection de PHP contre les scripts incontrôlables, et PHP précise que cette solution n’est pas encore aboutie. Aucune de ces mesures ne constitue un correctif. Considérez-les comme des mesures temporaires jusqu’à ce que tous les serveurs aient été mis à jour.

Pourquoi le PHP « en fin de vie » constitue un problème plus grave

La page consacrée aux versions prises en charge par PHP est très claire à ce sujet. Les branches 8.4 et 8.5 bénéficient d’un support actif, les versions 8.2 et 8.3 ne reçoivent que des correctifs de sécurité, et toutes les versions antérieures sont en fin de vie. Les branches en fin de vie ne bénéficient d’aucune mise à jour de sécurité de la part de php.net, et même une faille RCE critique n’y change rien.

Les chiffres concernant les installations encore en service ne sont pas réjouissants. Le 20 octobre, Mallory a recensé environ 884 000 serveurs exposés à Internet dont la bannière HTTP indiquait une version de PHP 8.1 ou antérieure, soit environ 59 % des serveurs ayant signalé une version. Les bannières ne constituent pas une confirmation d’exposition, et certains de ces serveurs utilisent des paquets rétroportés. Il s’agit néanmoins d’un nombre stupéfiant de serveurs exposés à Internet signalant une version obsolète de PHP.

Les installations qui posent problème sont celles que personne ne considère comme des serveurs PHP. Les appliances des fournisseurs. Les logiciels Windows qui intègrent leur propre php-cgi.exe (ELS for Runtimes propose également des versions PHP pour Windows, précisément pour cette raison). Panneaux de contrôle. Un wiki interne créé par quelqu’un en 2017 et dont personne n’a plus jamais parlé.

Imaginez une agence de 30 personnes hébergeant plusieurs centaines de sites WordPress de clients sur un seul serveur cPanel, dont la moitié des comptes sont bloqués sur PHP 7.4 parce qu’un thème premium ne fonctionne pas correctement sous la version 8.x. Personne ne va migrer tous ces sites vers PHP 8 d’ici vendredi. La mise à niveau de PHP est un projet applicatif, et c’est précisément pour cette raison que tant d’installations de PHP 7.x sont encore en service.

C'est précisément cette lacune qu'ELS for Runtimes vise à combler. TuxCare rétroporte les correctifs de sécurité vers les branches en fin de vie ; ainsi, un site resté sur la version 7.4 bénéficie du correctif php2shell sans avoir à subir une migration forcée vers PHP 8 alors qu'une vulnérabilité RCE est active. La migration doit tout de même avoir lieu, mais elle peut se faire selon le calendrier choisi par l'utilisateur.

Origine du correctif « php2shell », par branche, avec les dates de prise en charge indiquées par PHP :

Ces deux avis de sécurité mentionnent les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 comme étant celles pour lesquelles des correctifs ont été apportés, et le journal des modifications de PHP fournit les détails par branche. Installez la version qui vous concerne, puis vérifiez que les processus chargés de traiter les requêtes l'utilisent bien.

Si PHP provient des dépôts de votre distribution Linux, c'est son avis de sécurité qui fait foi. Les distributions effectuent souvent des rétroportages de correctifs sans modifier le numéro de version en amont ; par conséquent, la chaîne de version à elle seule ne permet pas de trancher.

Procurez-vous ELS pour Runtimes dès aujourd'hui →

PHP n'en est pas à son coup d'essai

En mai 2012, des informations ont été révélées concernant la vulnérabilité CVE-2012-1823, une faille permettant l'exécution de code à distance dans php-cgi, ont été rendues publiques par inadvertance avant que le correctif ne soit prêt. L'équipe PHP a publié en urgence les versions 5.3.12 et 5.4.2. Stefan Esser et d'autres ont rapidement démontré que le correctif pouvait être contourné, et PHP a dû publier une nouvelle version quelques jours plus tard, car Computerworld a rapporté que à l'époque.

Il y a ensuite la vulnérabilité CVE-2024-4577, qui concerne Windows php-cgi injection d'arguments à partir de juin 2024. Akamai a constaté des tentatives d'exploitation visant ses honeypots dans les 24 heures qui ont suivi la divulgation, selon The Hacker News.

Les failles de sécurité divulguées réduisent les délais de tout le monde, y compris ceux des développeurs chargés de rédiger le correctif, et les correctifs élaborés dans l'urgence nécessitent parfois une deuxième révision. Continuez à suivre les avis de sécurité pendant quelques jours après l'application du correctif.

Découvrez ce que PHP génère

Les vulnérabilités RCE au niveau de l'interpréteur se présentent généralement de la même manière, quel que soit le mode de fonctionnement du bug. Un worker PHP tel que php-fpm, php-cgi, lsphp ou bien un processus Apache lance quelque chose qu'il ne lance normalement jamais. Des shells, Python ou Perl, curl ou wget. Les lignes de commande contenant /dev/tcp/ ou mkfifo sont des indices classiques d'un « reverse shell », tout comme un php -r appel en une seule ligne fsockopen. Une rafale de whoami, id ou uname -a le fait d'exécuter un processus en tant qu'utilisateur du serveur web peut indiquer qu'une personne effectue une reconnaissance. Aucun de ces éléments ne constitue à lui seul une preuve, car les outils d'administration effectuent en partie les mêmes opérations. Ce qui importe, c'est la présence d'une arborescence de processus inhabituelle qui coïncide avec une requête ou un fichier récemment créé.

Sur les serveurs Linux dépourvus de système de détection des points d'accès, l'outil gratuit « process-watcher » de Florian Roth enregistre chaque programme lancé par un processus PHP, avec sa ligne de commande complète. Roth précise d'emblée que cet outil n'empêche rien : il se contente d'observer. En attendant, voici un aperçu rapide d'un instant donné :

ps -eo pid,ppid,user,args --forest | grep -A3 '[p]hp-fpm'

Si vous constatez quelque chose d’anormal, isolez le serveur et conservez les journaux du serveur web et de PHP avant que quiconque ne « fasse le ménage ». Un journal d’accès « propre » ne signifie pas pour autant que tout va bien, car les journaux par défaut n’enregistrent pas les corps des requêtes POST. Recherchez les webshells, les nouveaux fichiers dans le répertoire racine du site, les nouvelles tâches cron et les nouveaux comptes. Appliquer un correctif à un hôte compromis revient à fermer la porte alors que l’intrus se trouve encore à l’intérieur. Lorsqu’il n’est pas possible d’appliquer immédiatement un correctif, le CERT-EU recommande d’envisager de retirer les applications exposées à Internet des réseaux publics jusqu’à ce qu’un correctif soit mis en place. Un WAF ou un VPN déployé devant une ancienne succursale permet de gagner du temps, mais c’est tout ce qu’il permet.

L'inventaire vient en premier, et la liste est généralement plus longue que ce à quoi on s'attend. Cette boucle vérifie les emplacements habituels sous Linux, les versions ELS sous /opt/alt/ et affiche la version indiquée par chaque fichier binaire. C'est un point de départ, car les versions personnalisées et les packs fournis par les éditeurs peuvent se trouver n'importe où :

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

Cela indique ce qui se trouve sur le disque, et non ce que chaque site exécute, car les pools FPM, les serveurs virtuels et les panneaux de contrôle peuvent chacun pointer vers un binaire différent. Vérifiez également ces configurations. Les branches prises en charge bénéficient des mises à jour en amont ou de la distribution. Les versions d’ELS for Runtimes sont mises à jour via le gestionnaire de paquets habituel, à l’aide des commandes indiquées dans la documentation PHP d’ELS for Runtimes de TuxCare. Sur les systèmes basés sur RPM, la commande est `sudo yum update alt-php*`. Sous Debian et Ubuntu, actualisez les listes de paquets et mettez à jour les paquets alt-php :

sudo apt-get update
sudo apt-get upgrade alt-php*

Ensuite, l'étape qui est souvent négligée. L'installation du paquet corrigé ne suffit pas tant que les workers continuent d'exécuter l'ancien code. Un maître PHP-FPM en cours d'exécution, ou mod_php chargé au sein d’Apache, conserve l’ancien code en mémoire jusqu’à son redémarrage, tandis qu’un conteneur le conserve jusqu’à ce qu’il soit remplacé. Les serveurs d’hébergement mutualisé comportant des dizaines de pools FPM constituent un cas d’école : une version est redémarrée, mais trois autres ne le sont pas. Vérifiez que tous les maîtres FPM ont bien démarré après l’application de la mise à jour :

ps -eo pid,lstart,args | grep '[p]hp-fpm: master'

Enfin, ne clôturez pas le ticket en vous basant sur la comparaison de version en amont effectuée par un scanner. Une version ELS ou une version de distribution rétroportée peut encore indiquer le numéro de version en amont d’origine ; ainsi, les scanners qui se contentent de lire les chaînes de version peuvent signaler des hôtes qui ont déjà été corrigés. Lorsque vos outils le permettent, alimentez-les avec les données de sécurité lisibles par machine de TuxCare, qui incluent les flux OVAL et CSAF. Enregistrez le paquet installé, l’avis de sécurité auquel il répond et le processus qui traite effectivement les requêtes, car c’est ce qu’un auditeur vous demandera.

Pourquoi php2shell est-il si important ?

Un runtime est une dépendance, et ne plus assurer sa prise en charge signifie que chaque nouvelle vulnérabilité au cœur du système peut rester non corrigée indéfiniment. Les équipes surveillent attentivement leurs paquets Composer, puis les exécutent sur un interpréteur qui ne bénéficie plus de correctifs de sécurité depuis des années.

Cette fuite a également montré à quel point le délai d'alerte est court. Les premières rumeurs ont été confirmées en quelques heures, le correctif a été déployé dès le lendemain, et des tentatives d'attaque ont été détectées avant même sa mise en place. Une approche du type « nous effectuerons la mise à jour au trimestre prochain » ne tient pas la route face à un tel calendrier.

Une solution « à faire soi-même » a également fait son apparition. PHP a intégré des backports pour les versions 7.4, 8.0 et 8.1 dans php-src sans créer de versions officielles, et les scripts de la communauté recompilent désormais PHP à partir du code source à l'aide de ces backports. Cela peut fonctionner pour un seul serveur compilé manuellement, mais cela ne corrige que la faille php2shell et rien d'autre, ignore les paquets de distribution, `mod_php` et `lsphp`, et transforme chaque future vulnérabilité CVE de PHP en un nouveau projet de compilation.

Appliquez donc dès maintenant les correctifs aux branches prises en charge, puis redémarrez ce qui doit l'être. Pour les versions de PHP que php.net a abandonnées, transférez-les vers une version ELS corrigée ou retirez-les d'Internet, puis inscrivez la véritable migration dans un calendrier plutôt que de la laisser sur une liste de souhaits.

Procurez-vous ELS pour Runtimes dès aujourd'hui →

Chronologie

Références

Les sources principales de cet article sont les avis de sécurité PHP concernant l’exécution de code à distance (RCE) via une corruption OOM (CVE-2026-109618) et l’exécution de code à distance (RCE) via un état global obsolète (CVE-2026-109619), l’avis préalable de l’équipe de sécurité PHP publié sur php.announce (20 octobre 2026), la page des versions prises en charge par PHP et le journal des modifications de PHP 8, la FAQ sur php2shell de watchTowr, les recherches de Sansec sur php2shell, le compte-rendu de réponse rapide de Huntress, l’avis de sécurité 2026-018 du CERT-EU, l’analyse d’exposition de Mallory, le process-watcher de Florian Roth, les entrées du NVD pour les CVE-2026-109618 et CVE-2026-109619, la couverture médiatique de The Hacker News, ainsi que la documentation ELS for Runtimes PHP de TuxCare.