PHP2Shell secoue le web

Le 21 octobre 2026, le projet PHP publie des correctifs d'urgence pour deux failles critiques — CVE-2026-109618 et CVE-2026-109619, notées 9.2 sur 10 (CVSS v4.0), déjà surnommées PHP2Shell. Amazon Threat Intelligence avait détecté une tentative d'exploitation quatre jours avant la divulgation publique. Depuis, Palo Alto Networks recense plus de 22,6 millions d'instances potentiellement exposées, et au moins un gouvernement européen a coupé un site par précaution. Ce n'est pas une faille de framework ou de dépendance : elle est dans le moteur Zend lui-même, celui qui fait tourner ce blog comme n'importe quel site PHP.

Le mécanisme : une erreur fatale qui ne nettoie pas derrière elle

Les deux CVE touchent la même zone du moteur : la gestion des erreurs fatales via longjmp(), une primitive du C qui permet d'interrompre brutalement l'exécution pour sauter directement à un point de reprise, en court-circuitant la pile d'appels normale. PHP s'en sert en interne pour gérer les erreurs fatales et les situations de mémoire épuisée — mais court-circuiter la pile d'appels veut aussi dire court-circuiter le code de nettoyage qui s'y trouvait.

• CVE-2026-109618. Si la mémoire s'épuise pendant l'initialisation des données internes d'une requête, le longjmp() déclenché saute directement au nettoyage sans attendre que l'initialisation se termine. Le nettoyage traite alors des données partiellement construites comme si elles étaient valides.
• CVE-2026-109619. Même primitive, autre dégât : l'état global du moteur continue de pointer vers une zone mémoire libérée après le traitement d'une requête. C'est un use-after-free classique, sauf qu'ici la zone corrompue n'est pas relue dans la même requête — elle est relue par la requête suivante, traitée par le même worker.

C'est ce deuxième point qui change la portée du problème. Un serveur PHP ne redémarre pas un processus par requête : PHP-FPM, Apache avec mod_php, FrankenPHP ou LiteSpeed réutilisent le même worker pour des centaines de requêtes successives, précisément pour éviter le coût d'un nouveau démarrage à chaque fois. Normalement, cette réutilisation suppose que chaque requête reparte d'un état propre. Avec CVE-2026-109619, une seule requête malformée peut laisser un worker dans un état corrompu que la requête suivante — venue d'un visiteur ordinaire, ou de l'attaquant lui-même — va exploiter.

Qui est concerné

D'après l'avis officiel, toute installation qui sert des requêtes web est à risque : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est maximal sous mod_php, où l'exploit de démonstration peut être déclenché par une requête non authentifiée, avant même que le code applicatif ne s'exécute — inutile de trouver une faille dans le framework ou l'appli, le moteur PHP suffit.

Votre version est-elle couverte ?

Un petit vérificateur, entièrement côté navigateur :

Ce qui se passe après l'intrusion

Les premiers rapports d'exploitation montrent une suite automatisée très rapide : récupération des empreintes de mots de passe, des secrets MFA, établissement de tunnels NTLM-relay et tentatives d'escalade vers un compte Domain Admin, le tout en moins de deux heures après la compromission initiale. Des chercheurs évoquent des attaquants agentiques pilotant cette chaîne post-exploitation — pas un script figé, mais quelque chose qui décide de la suite au fur et à mesure. C'est la même tendance que documentait cet article sur l'attaque RubyGems : dès qu'une RCE est publique, des agents prennent le relais de la partie la plus fastidieuse — reconnaissance, pivot, escalade — à une vitesse qu'aucune équipe de réponse à incident humaine ne peut suivre.

Un deuxième avertissement, plus discret

Deux jours après les premiers correctifs, PHP a publié un second avis — CVE-2026-115560 — sans patch immédiat cette fois. La faille ne touche que les applications qui changent session.serialize_handler en cours d'exécution via ini_set(), avant d'appeler session_start(), avec le suivi de progression d'upload (session.upload_progress) activé — une configuration jugée assez rare pour que le correctif suive le cycle de release normal plutôt qu'un patch d'urgence. En attendant, la mitigation recommandée est simple : désactiver session.upload_progress.enabled. Le traitement de ce second cas — divulgation publique, gravité réévaluée, correctif différé plutôt que caché — contraste avec la manière dont l'incident Gemini avait été géré en mai, où l'information n'était sortie que deux mois après l'alerte : ici, même un risque jugé faible est documenté tout de suite, avec une mitigation actionnable immédiatement.

Ce qu'il faut en retenir

Le patch lui-même est la partie facile — une mise à jour vers une version déjà publiée. Ce qui mérite d'être retenu, c'est la mécanique : dans une architecture à workers réutilisés, qui est l'écrasante majorité du PHP en production, une seule requête malveillante peut laisser une trace exploitable pour la requête suivante. Le use-after-free n'est pas une nouveauté en soi, mais son terrain de jeu ici — le cycle de vie d'une requête web, répété des milliers de fois par heure sur le même processus — en fait un vecteur bien plus large qu'un bug mémoire ordinaire.

FAQ

Qu'est-ce que PHP2Shell ?

Le surnom donné à deux vulnérabilités critiques du moteur PHP (CVE-2026-109618 et CVE-2026-109619), notées 9.2/10, permettant l'exécution de code à distance sans authentification. Corrigées en urgence le 21 octobre 2026.

Mon site est-il concerné si je n'ai pas mis à jour ?

Probablement, si votre installation sert des requêtes HTTP via PHP-FPM, mod_php, php-cgi, FrankenPHP ou LiteSpeed — c'est-à-dire la quasi-totalité des déploiements PHP réels. Le risque est maximal sous mod_php.

Et le second CVE, CVE-2026-115560 ?

Une faille distincte, jugée à faible risque car elle ne touche que des applications avec une configuration de session particulière. Pas de patch d'urgence : PHP recommande de désactiver session.upload_progress.enabled en attendant le prochain correctif de routine.