PHP2Shell : deux failles RCE, mettez PHP à jour

Ce qui se passe

Le 21 octobre 2026, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, la version de sécurité annoncée la veille. Elle corrige deux failles critiques, chacune notée 9,2 en CVSS v4.0, qui permettent à un attaquant sans compte d'exécuter du code sur le serveur. La CISA et Cloudflare désignent l'ensemble sous le nom PHP2Shell.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), corruption mémoire à la saturation. Quand une requête atteint memory_limit au pire moment, PHP peut abandonner des données internes à moitié initialisées, que le nettoyage de la requête traite ensuite comme valides. Sous Apache avec mod_php, une requête anonyme déclenche le défaut avant que le code de l'application ne tourne ; l'exécution de code a été démontrée avec la configuration par défaut, et confirmée sous PHP-FPM par des chemins applicatifs.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), état global périmé. Une erreur fatale mal placée laisse un état interne pointer vers la mémoire d'une requête précédente ; la requête suivante, traitée par le même worker, s'en sert alors qu'elle est libérée. Use-after-free et plantage confirmés, exécution de code démontrée contre une application réelle sous Apache et mod_php.

Les deux logent dans la gestion de la mémoire et des erreurs, que presque chaque requête traverse. C'est ce qui les rend graves, et difficiles à corriger sans casser la compatibilité des extensions tierces.

Qui est exposé

Toute installation qui sert des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est le plus élevé avec mod_php.

• PHP 8.1 et antérieurs ne reçoivent plus de mises à jour du projet. Des distributions et des fournisseurs LTS rétroportent le correctif ; pour qui compile depuis les sources, le projet a publié des rétroportages minimaux sur les branches PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 et PHP-8.1-CVE-2026-109618-109619 de php-src.
• PHP 8.2 s'arrête le 31 décembre 2026 : plus de correctif de sécurité après cette date.
• PHP 8.6.0 RC4 contient aussi les correctifs, mais n'est pas destiné à la production.

Une divulgation qui a déraillé

Chronologie de la PHP Foundation, en UTC :

• mardi 20 octobre, vers 15:00 : les deux identifiants circulent sur des forums, avec une mauvaise heure de sortie et un CVSS faussement donné à 10,0 ;
• 19:30 : le préavis est publié, et la sortie passe du 22 octobre au 21 octobre, 14:00 ;
• vers 20:00 : Calif, l'une des sociétés qui avaient signalé les failles, publie par erreur une vidéo de sa preuve de concept ; des copies circulent ;
• mercredi 21 octobre, 07:41 : Chainguard publie des images contenant le correctif plus de six heures avant la sortie coordonnée.

À la sortie, l'équipe PHP n'avait pas identifié d'exploit fonctionnel parmi les preuves de concept apparues, et la CISA ne notait aucune exploitation observée. Simon Willison signale pourtant des exploits en circulation depuis la nuit précédente : mieux vaut supposer la menace active. Cloudflare a déployé des règles WAF par défaut avant la divulgation : utile, mais cela ne remplace pas le correctif.

Comment s'y prendre

1. Inventorier : php -v sur chaque serveur, mais aussi les images Docker, les hébergements mutualisés et la CI.
2. Installer 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou le paquet corrigé de la distribution), reconstruire les images, puis redémarrer chaque worker.
3. En attendant seulement, ces réglages ferment certains chemins et ne rendent pas le serveur sûr :
   • CVE-2026-109618 : memory_limit=-1, posé de façon non surchargeable (php_admin_value dans le pool FPM ou la configuration Apache) ; post_max_size = 8M sans envoi de fichiers, 32M avec, et upload_max_filesize en dessous ; une limite par conteneur ou cgroup qui ne tue que le worker concerné, jamais RLIMIT_AS ni RLIMIT_DATA, qui provoquent l'échec d'allocation vulnérable.
   • CVE-2026-109619 : session.upload_progress.enabled=0 dans php.ini ou le pool FPM (ni ini_set() ni .user.ini), puis redémarrage de tous les workers ; sur PHP 8.5, fatal_error_backtraces=0 ; corriger les erreurs fatales et les délais d'exécution qu'un attaquant peut provoquer.

Source : PHP.net, avis de sécurité du 21 octobre 2026. Source en anglais. Compléments : PHP Foundation (chronologie de la fuite), CISA, Cloudflare.