Le problème en deux phrases
Une requête HTTP sans authentification peut corrompre l’état interne de PHP et mener à l’exécution de code, avant même que l’application ne démarre. WordPress, Magento, PrestaShop ou une application maison : tout site servi par PHP est concerné, qu’il soit à jour ou non. Selon l’équipe de sécurité de PHP, toutes les installations qui servent des requêtes web sont touchées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php, pour lequel un exploit fonctionnel a été démontré.
Les détails techniques complets sont dans les avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp.
Chronologie
Le correctif public indique désormais aux attaquants où regarder : les attaques vont s’intensifier sur les serveurs qui ne sont pas encore à jour.
Ce que nous avons fait chez OnetSolutions
Mitigation appliquée avant le correctif. Le 21 octobre, avant la publication des versions corrigées, nous avons désactivésession.upload_progress sur tous nos serveurs d’hébergement web, pour toutes les versions de PHP proposées (de 7.0 à 8.4). Nous avons contrôlé les valeurs effectives version par version.
Correctif installé le jour même. Nos équipes étaient mobilisées dès la fuite et ont suivi la situation en continu. Les versions corrigées de PHP ont été installées sur l’ensemble de notre hébergement web le jour même de leur publication, pour toutes les versions proposées, y compris PHP 7.0 à 8.1 qui reçoivent un correctif rétroporté. La mitigation reste en place en complément.
Surveillance. L’analyse antimalware en temps réel reste active sur nos serveurs d’hébergement web.
La mitigation réduit la surface d’attaque, elle ne la supprime pas. L’équipe de PHP est claire : seule la mise à jour corrige ces failles.
Évaluer son exposition
Vous administrez votre VPS : c’est à vous d’y installer le correctif. Les sections suivantes donnent les commandes.
Mettre à jour PHP
Les distributions Linux ont reçu les correctifs en avance : leurs paquets arrivent dans les heures qui suivent la publication.Si vous ne pouvez pas mettre à jour tout de suite
L’équipe de PHP liste des mesures qui ferment certains chemins d’attaque connus. Elle prévient qu’elles ne rendent pas une installation sûre.Contre CVE-2026-109619 (état global périmé)
Désactivez le suivi de progression des envois de fichiers, dans lephp.ini ou un fichier conf.d chargé au démarrage, puis redémarrez tous les processus. Un ini_set() ou un .user.ini ne suffit pas : le réglage doit s’appliquer avant l’analyse de la requête.
/etc/php/8.3/fpm/pool.d/www.conf) :
fatal_error_backtraces = 0 : cela ferme le chemin d’attaque confirmé par les traces d’erreurs fatales.
Contre CVE-2026-109618 (manque de mémoire)
Réduisez la taille maximale des requêtes :post_max_size = 8M si l’application ne reçoit pas de fichiers, 32M si elle en reçoit, avec upload_max_filesize inférieur à post_max_size.
L’équipe de PHP suggère aussi memory_limit = -1, à condition qu’une limite de mémoire par conteneur ou par cgroup protège le serveur. Sans cette limite, un seul processus peut consommer toute la mémoire de la machine : ne l’appliquez pas à la légère.
Vérifier
session.upload_progress.enabled => Off.

