Failles PHP 2026 : PHP2Shell et votre dette technique

Le 21 octobre 2026, l'équipe PHP a publié une annonce intitulée « Security advisory: Critical remote code execution vulnerabilities, update now ». Deux failles, CVE-2026-109618 et CVE-2026-109619, regroupées par les chercheurs sous le nom PHP2Shell. Toutes deux permettent à un visiteur non authentifié d'exécuter son code sur votre serveur, et l'annonce officielle ne laisse pas de marge : aucun réglage ne met à l'abri, seule la mise à jour le fait.

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Vous trouverez plus bas de quoi vérifier où vous en êtes, mais ce n'est pas l'objet principal de cet article. Ce qui m'a frappé en patchant les serveurs dont je m'occupe, c'est que la faille était rigoureusement la même partout, alors que le temps passé à la corriger, lui, n.avait rien de comparable d.un site à l.autre. Cet écart ne parle pas de sécurité. Il parle de dette technique.

Les deux failles PHP de 2026, en clair

Les deux bugs vivent dans le cœur du moteur, pas dans votre code ni dans vos dépendances.

CVE-2026-109618, « RCE via OOM corruption ». Quand PHP arrive à bout de mémoire pendant la mise en place d'une requête, il laisse derrière lui des structures internes à moitié initialisées. Le code de nettoyage les reprend ensuite comme si elles étaient complètes et valides.

CVE-2026-109619, « RCE via stale global state ». Un état interne attaché à une requête survit à la libération de la mémoire qui le porte. La requête suivante traitée par le même worker peut tomber dessus avant sa réinitialisation.

Les deux sont notées 9.2 sur l'échelle CVSS v4.0 et remontent, selon l'advisory de Laravel Forge, à des versions de PHP publiées en 2004. Tout ce qui sert des requêtes web est concerné : PHP-FPM, mod_php, php-cgi, LiteSpeed, FrankenPHP. L'équipe PHP juge le risque maximal sur mod_php, où une requête non authentifiée peut déclencher l'attaque avant même que la moindre ligne de votre application ne s'exécute. Autrement dit, ni votre middleware d'authentification, ni vos règles de validation, ni la qualité de votre code n'entrent en jeu.

Les versions à installer

Les versions corrigées, publiées le 21 octobre 2026 :

• PHP 8.5 : 8.5.12
• PHP 8.4 : 8.4.27
• PHP 8.3 : 8.3.36
• PHP 8.2 : 8.2.35
• PHP 8.1 et antérieures : fin de vie, aucune nouvelle release. Le projet a publié un backport minimal, et votre distribution peut fournir son propre paquet corrigé.

C'est ce dernier point qui fait toute la différence de traitement, et j'y reviens dans un instant.

Ce que j'ai vu en patchant mes serveurs

J'administre une machine qui héberge à la fois des boutiques PrestaShop et des applications Laravel. Plusieurs versions de PHP y cohabitent, parce que chaque site a été mis en ligne à une époque différente et qu'aucun n'a envie de bouger. La première chose que fait ce genre d'inventaire, c'est de rappeler qu'une version de PHP installée est vulnérable même si aucun site ne s'en sert activement : le binaire est là, le pool FPM est souvent là aussi, et personne ne se souvient pourquoi.

Résultat : il a fallu patcher toutes les versions présentes sur la machine, y compris celles qu'aucun virtual host ne pointe plus. Et pour les sites en branche supportée, l'opération tient en une mise à jour de paquets et un redémarrage. Pour les autres, celles coincées sur une version en fin de vie, la question n'est plus « comment je patche » mais « est-ce que mon application démarre encore sur une version récente ». Ce n'est plus de la sécurité, c'est de la migration.

PHP2Shell n'a pas créé votre dette technique, il l'a facturée

Une faille critique dans le cœur de PHP est une épreuve de vitesse. Le temps que vous mettez à y répondre est exactement la somme des décisions que vous avez repoussées avant.

Sur une application en PHP 8.3 ou 8.4, avec des dépendances à jour et une suite de tests qui tourne, la séquence est connue : vous mettez à jour les paquets, vous redémarrez FPM et les workers, vous relancez les tests, et c'est réglé. Sur une application restée en PHP 8.0 ou 8.1, vous n'avez que deux portes, et aucune n'est confortable. Soit vous appliquez le backport de votre distribution, qui vous remet dans la course mais sur une branche qui ne recevra plus de correctifs réguliers, donc vous aurez la même conversation à la prochaine CVE. Soit vous migrez, c'est-à-dire que vous faites sous pression le chantier que vous auriez pu étaler tranquillement sur plusieurs semaines.

Il y a un détail qui résume bien le problème. Sur PHP 8.1 et antérieures, le correctif arrive sous forme de révision de paquet : le numéro de version ne change pas, php -v affiche exactement la même chose avant et après. Vous ne pouvez donc même pas vérifier d'un coup d'œil que vous êtes protégé. Une application qu'on ne peut pas mettre à jour, c'est aussi une application dont on ne peut pas prouver l'état.

La dette technique n'est pas une question d'élégance du code. C'est le délai entre le moment où un correctif existe et le moment où vous pouvez l'appliquer sans rien casser. PHP2Shell a mis ce délai sur la table, pour tout le monde, le même jour.

Comment vérifier où vous en êtes

Sur un serveur Ubuntu avec les paquets d'Ondřej Surý, le point de départ est de lister ce qui est réellement installé, pas ce que vous croyez utiliser :

ls /etc/php
php8.4 -v
php-fpm8.4 -v

Vérifiez bien le binaire FPM en plus du binaire CLI : c'est FPM qui sert vos pages, et il garde l'ancien code en mémoire jusqu'à son redémarrage. Pour une branche en fin de vie, où le numéro de version ne bouge pas, contrôlez la révision du paquet :

dpkg -l 'php8.1*' | awk '/^ii/ {print $2, $3}'

Enfin, les processus PHP de longue durée continuent de tourner sur l'ancien binaire jusqu'à ce qu'on les relance. Sur une application Laravel, cela vise les queue workers, Horizon, Octane et Reverb :

php artisan queue:restart
php artisan horizon:terminate
php artisan octane:reload

Les chemins et noms de paquets ci-dessus valent pour Ubuntu avec les paquets Surý. Sur un hébergement mutualisé, un panel ou une image Docker, la mécanique diffère, mais les trois questions restent les mêmes : quelles versions sont installées, lesquelles servent du trafic, et qu'est-ce qui tourne encore en mémoire.

Les quatre questions à poser si vous ne gérez pas vos serveurs

Si la technique n'est pas votre métier, vous n'avez pas à lire un diff de php-src. Vous avez quatre questions à poser à votre hébergeur ou à votre prestataire, et les réponses doivent être précises :

1. Quelles versions de PHP sont installées sur la machine, et laquelle sert mon site ?
2. Cette version est-elle au niveau corrigé du 21 octobre 2026, et comment le vérifiez-vous ?
3. Les processus de fond (tâches planifiées, files d'attente) ont-ils été redémarrés après la mise à jour ?
4. Si mon site tourne sur une version en fin de vie, quel est le plan de migration, avec quelle date ?

Une réponse du type « tout est à jour » sans numéro de version n'est pas une réponse. Et si la quatrième question reste sans date, vous connaissez déjà le déroulé de la prochaine alerte.

À retenir

• Deux failles critiques dans le cœur de PHP, corrigées le 21 octobre 2026 en 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Aucune configuration ne protège complètement : la mise à jour est la seule issue.
• Patchez toutes les versions installées sur la machine, pas seulement celle de votre site.
• Redémarrez FPM et les processus de longue durée, sinon le correctif n'est pas actif.
• Sur une version en fin de vie, le backport vous fait gagner du temps, pas la partie. Planifiez la migration maintenant, pendant que ce n'est pas urgent.

Questions fréquentes

Mon site est derrière un pare-feu applicatif ou un CDN, suis-je protégé ? Non. L'équipe PHP indique qu'aucune mesure d'atténuation ne couvre complètement ces deux failles. Un filtrage en amont réduit l'exposition, il ne corrige pas le moteur qui exécute vos pages.

Mon hébergeur mutualisé a-t-il patché pour moi ? Souvent oui, parfois avec plusieurs jours de retard, et rarement pour les versions de PHP en fin de vie qu'il laisse disponibles. Demandez la version exacte en service sur votre compte et la date de la mise à jour.

Après la mise à jour, php -v affiche toujours la même version. C'est normal ? Sur PHP 8.1 et antérieures, oui : le correctif est livré comme révision de paquet, le numéro de version ne change pas. Vérifiez la révision installée avec dpkg -l.

Faut-il mettre à jour Laravel en même temps ? Ce sont deux sujets distincts : la faille est dans PHP, pas dans le framework. Mais si votre application vous empêche de passer sur une version de PHP supportée, c'est bien là qu'il faut agir, et c'est un chantier de migration, pas un correctif de sécurité.

Besoin d'un avis extérieur sur l'état de vos applications

Cette release m'a fait passer en revue des machines qui hébergent du PrestaShop et du Laravel côte à côte. Si vous avez une application Laravel bloquée sur une vieille version de PHP, un projet repris sans documentation, ou simplement l'envie de savoir combien de temps vous coûterait la prochaine alerte, je fais ce travail de reprise, d'audit et de maintenance au quotidien. Vous pouvez voir le genre de projets dont je m'occupe sur mes réalisations Laravel.