Publié le 26 octobre 20268 min de lecture

PHP2Shell : patchez PHP, puis considérez vos secrets fuités

Le 21 octobre, le projet PHP a publié des versions d’urgence pour deux vulnérabilités surnommées PHP2Shell : CVE-2026-109618 (corruption liée à l’épuisement mémoire) et CVE-2026-109619 (état global résiduel, un use-after-free). Les deux sont notées CVSS v4.0 9.2 et permettent à un attaquant distant non authentifié d’exécuter du code avec les droits du worker PHP.

L’équipe sécurité de Drupal a publié le PSA-2026-10-20 le même jour. Sa formulation est inhabituellement directe : « Mettre à jour vers une version de PHP contenant le correctif de ces vulnérabilités est la seule mitigation complète. »

Cinq jours plus tard, voici ce qui compte vraiment — y compris la partie que la plupart des articles enterrent.

Êtes-vous concerné ? Presque certainement oui

La faille est dans PHP lui-même, pas dans un framework ni dans un module. Toute installation qui sert des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP considère mod_php comme le plus exposé, car la requête peut y être traitée avant même que le code applicatif ne s’exécute.

Branche	Version corrigée
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35
PHP 7.4 – 8.1	Aucune version amont — mais votre distribution l’a probablement corrigé. Voir plus bas
PHP 5.4 – 7.3	Fin de vie. Aucun correctif du projet PHP

Vérifiez ce que vous exécutez réellement, pas ce que vous croyez exécuter :

php -v          # le binaire CLI — souvent PAS celui qui sert votre site
php-fpm -v      # le binaire FPM, qui l'est généralement

Sous Debian, Ubuntu et RHEL, php -v vous mentira sur l’état du correctif. Les distributions rétroportent le fix dans la version qu’elles livrent déjà : la chaîne de version ne change donc jamais. Une machine Ubuntu 22.04 corrigée affiche toujours 8.1.2. Vérifiez plutôt la version du paquet :

dpkg -l | grep -E "^ii\s+php[0-9.]+-(fpm|cli)"   # Debian / Ubuntu
rpm -q php-fpm                                   # RHEL / Alma / Rocky

Le piège joue dans les deux sens : certains se déclarent vulnérables alors qu’ils sont à jour, et à jour alors qu’ils sont vulnérables. Faites confiance au gestionnaire de paquets, pas à la bannière.

Mettre à jour Drupal ou WordPress ne change rien

C’est le malentendu qui fait perdre du temps cette semaine. Aucune version de Drupal ne corrige cela, et le PSA n’affirme pas que le cœur de Drupal est vulnérable : il situe le problème dans le runtime et rappelle que « le périmètre de l’équipe sécurité de Drupal reste limité au code hébergé sur les systèmes de Drupal.org ». Même chose pour WordPress : aucune mise à jour d’extension, de cœur ou de plugin de sécurité ne corrige un trou dans le binaire PHP.

Si votre hébergeur gère PHP, c’est son travail et il vous faut son calendrier par écrit. Si c’est vous, c’est le vôtre. Des chercheurs de Wiz auraient démontré la chaîne d’exploitation sur des images conteneurs à jour de WordPress, Drupal et Joomla : « on est sur une stack standard » n’est donc pas rassurant.

Ce que l’on enterre : patcher n’annule pas une fuite

La CVE-2026-109618 permet à elle seule de divulguer de la mémoire serveur. L’analyse de Sansec décrit le gestionnaire d’upload-progress de PHP renvoyant de la mémoire de worker libérée au client dans un cookie PHPSESSID — une mémoire qui « peut contenir des mots de passe, des jetons de session, des clés d’API et des clés privées TLS issus d’autres requêtes ». Et cela fonctionne « même lorsque l’application n’appelle jamais session_start() ».

Relisez. La mémoire divulguée provient des requêtes d’autres personnes sur le même worker. La requête d’un attaquant peut lui livrer le jeton de session d’un autre visiteur.

Aucun des avis que j’ai lus ne vous dit de renouveler quoi que ce soit. Ils vous disent de patcher. C’est juste mais incomplet, et c’est ma principale raison d’écrire ceci : le correctif referme le trou, il ne rappelle pas ce qui est déjà sorti. Si vous étiez exposé sur Internet avec une version vulnérable — c’est-à-dire tout le monde avant le 21 octobre — mon avis est de considérer les éléments suivants comme potentiellement divulgués et de les renouveler :

Clés de session et hash_salt (Drupal) / AUTH_KEY et consorts (WordPress), puis forcer la reconnexion
Identifiants de base de données
Clés d’API et jetons présents dans la configuration ou l’environnement
Identifiants SMTP et prestataires de paiement
Clés privées TLS, si la terminaison TLS se fait sur la même machine que PHP

C’est un jugement professionnel, pas une consigne d’éditeur, et le renouvellement a son propre coût opérationnel. Décidez-le délibérément. Mais « on a patché mercredi » n’équivaut pas à « on est propre ».

Vous ne saurez probablement pas si vous avez été touché

J’aimerais vous donner une signature de log. Il n’en existe pas de fiable publiquement. Sansec note que les chemins de RCE et de divulgation mémoire s’exécutent à l’intérieur de PHP, avant l’application des règles WAF : un log WAF propre ne prouve donc rien.

Ce que l’on sait du calendrier : Amazon Threat Intelligence a observé une tentative d’exploitation sur son réseau de honeypots le 17 octobre — quatre jours avant la divulgation publique — et recommande de faire remonter toute investigation au moins à cette date. Cloudflare a signalé des attaques précoces le matin du 21 octobre, avant la sortie du correctif.

Les sources divergent réellement sur l’ampleur. Amazon décrit une exploitation large ; Bitdefender n’en relevait aucune dans sa télémétrie au 22 octobre ; la Fondation PHP indiquait n’avoir identifié aucun exploit fonctionnel à la publication ; et au 23 octobre, aucune des deux CVE ne figurait au catalogue KEV de la CISA. Méfiez-vous des affirmations catégoriques dans un sens comme dans l’autre — y compris « il ne s’est rien passé ».

Fin de vie amont ne veut pas dire sans correctif

C’est le point que la plupart des articles ont manqué cette semaine, et c’est ce qui a sauvé beaucoup de monde — y compris des équipes avec lesquelles je travaille.

PHP 8.1 est en fin de vie amont depuis le 31 décembre 2025 : php.net ne livre donc plus rien. Mais votre distribution Linux n’est pas php.net. Canonical a publié des correctifs pour toutes les versions d’Ubuntu supportées affectées le 21 octobre, le jour même de la publication amont, via USN-8948-1 (et USN-8948-2 pour les versions Ubuntu Pro). Sur Ubuntu 22.04 LTS, php8.1 est corrigé en 8.1.2-1ubuntu2.28 — dans les mises à jour standard, sans abonnement Ubuntu Pro. Le changelog Launchpad porte une date mainteneur du 19 octobre, deux jours avant la divulgation publique : les distributions avaient été prévenues en amont.

Ubuntu 22.04 LTS continue de recevoir des mises à jour de sécurité gratuites jusqu’en 2027 — les sources divergent entre avril et mai 2027 pour la fin du support standard, vérifiez donc la page de cycle de vie de Canonical avant de bâtir une migration dessus, sachant qu’Ubuntu Pro/ESM prolonge la couverture jusqu’en 2032. Debian et les dérivés RHEL ont fait le même travail de rétroportage.

Il faut le dire : c’est un travail ingrat et invisible. Des équipes sécurité de distribution prennent un correctif écrit pour une branche qu’elles ne contrôlent pas et le greffent soigneusement sur une version abandonnée par l’amont depuis dix mois. L’équipe sécurité d’Ubuntu et plus largement les mainteneurs des communautés Debian et Ubuntu sont la raison pour laquelle une grande partie du web était corrigée dès le premier jour malgré PHP 8.1. Si vous vous en êtes tiré cette semaine sans rien faire d’héroïque, c’est eux qu’il faut remercier.

Les vrais laissés-pour-compte forment donc un groupe plus restreint mais bien réel : tous ceux en PHP 5.4 à 7.3, pour qui personne ne publie de correctif ; ceux qui ont compilé PHP depuis les sources sur une vieille branche ; ceux dont la version de distribution n’est elle-même plus supportée ; et ceux dont l’hébergeur mutualisé n’a tout simplement rien fait. C’est encore le site Drupal 7 que personne ne voulait migrer et l’installation WordPress sur un mutualisé bon marché. Pour ces cas, la consigne de la CISA est inconfortable et juste : si vous ne pouvez pas mettre à jour, mettez le système hors ligne en attendant.

C’est l’argument que je répète toute l’année sur un registre moins dramatique : dans le playbook sécurité Drupal, la fin de vie d’une version de PHP figurait comme méta-risque ; dans l’article sur la fin de vie de Drupal 10, comme échéance. PHP2Shell, c’est à quoi ressemble ce risque quand il se réalise : pas un déclin progressif, mais un mercredi où votre plateforme devient impossible à corriger.

Si vous ne pouvez vraiment pas patcher aujourd’hui

PHP a publié des réglages intermédiaires. Ils réduisent l’exposition sans rendre l’installation sûre, et chaque worker PHP doit être redémarré après application :

; CVE-2026-109618 — à poser pour que les applications ne puissent pas l'écraser
memory_limit = -1

; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 uniquement
fatal_error_backtraces = 0

Considérez-les comme un pont qui se compte en heures, pas comme une configuration que l’on garde.

En résumé

Passez en 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 aujourd’hui — ou au paquet corrigé de votre distribution, et vérifiez-le avec dpkg/rpm plutôt qu’avec php -v. Obtenez par écrit le calendrier de votre hébergeur s’il gère le runtime. Renouvelez vos secrets plutôt que de parier sur votre chance. Et si vous vous en êtes sorti uniquement parce que Canonical rétroportait encore pour vous, prenez-le comme l’avertissement que c’est : ce filet de sécurité a lui aussi une date d’expiration.

Bloqué sur une version de PHP en fin de vie, avec un site que personne n’ose toucher ? C’est exactement le travail de migration que je mène — et l’audit qui mesure votre exposition vient d’abord.