Passer au contenu principal
Publié le 21 octobre 2026
CVE-2026-109618 et CVE-2026-109619, CVSS v4.0 9,2 chacune. Deux exécutions de code à distance sans authentification dans le cœur de PHP, quelle que soit l’application. Les détails ont fuité avant la fin de l’embargo et des attaques sont observées depuis le 21 octobre au matin. Corrigé dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre. Mettez à jour maintenant.

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.
Redémarrez ensuite tous les processus PHP : l’une des deux failles vit dans l’état que conserve un processus d’une requête à l’autre.
Si vous utilisez le dépôt Remi (rpms.remirepo.net), il ne publiera pas de mise à jour le 21 octobre. L’équipe de PHP recommande de passer aux paquets de votre distribution ou de compiler depuis les sources.
PHP 8.1 et antérieur. Le projet PHP ne publie plus de version pour ces branches. Vu la gravité, son équipe de sécurité a tout de même publié des correctifs minimaux pour PHP 7.4, 8.0 et 8.1, à compiler soi-même. Certaines distributions et offres de support étendu les reprennent dans leurs paquets : renseignez-vous auprès de votre fournisseur, ou passez à une version maintenue.

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 le php.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.
Pour l’imposer dans un pool PHP-FPM précis, ajoutez à sa configuration (par exemple /etc/php/8.3/fpm/pool.d/www.conf) :
Sur PHP 8.5, ajoutez aussi 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

Attendu : session.upload_progress.enabled => Off.

Chercher des traces

Des attaques ont précédé le correctif. Sur un serveur qui a tourné avec une version vulnérable, cherchez les fichiers PHP créés ou modifiés depuis le 20 octobre :
Un fichier que vous n’avez pas déployé, en particulier dans un répertoire d’envoi de fichiers, signe une compromission. Traitez alors le serveur comme compromis : restaurez depuis une sauvegarde antérieure au 20 octobre et renouvelez les secrets qu’il détient.

Et après ?

La mitigation peut rester en place après la mise à jour : peu d’applications utilisent le suivi de progression des envois de fichiers. Le vrai sujet est ailleurs. PHP 8.1 et les versions antérieures ne reçoivent plus de versions officielles, et PHP 8.2 arrive en fin de vie le 31 décembre 2026. Si un de vos sites en dépend, c’est le moment de le migrer. Pour toute question, notre équipe est disponible depuis votre espace client.