Failles PHP critiques : Mesures de sécurité et recommandations

Mardi 20 octobre, un message sur Hacker News annonce deux failles PHP permettant d'exécuter du code à distance. Quelques heures plus tard, l'équipe de sécurité de PHP confirme et avance sa publication au mercredi 21 octobre, 14 h UTC. Les deux failles ont un score CVSS de 9,2, et un comptage par bannières évalue à environ 884 000 le nombre de serveurs encore en PHP 8.1 ou plus ancien, donc sans correctif officiel. Voici ce qu'il faut faire, version par version.

Ce qu'il faut retenir

• Deux failles critiques, CVE-2026-109618 et CVE-2026-109619, permettent une exécution de code à distance sans authentification. PHP les note 9,2 sur l'échelle CVSS v4.0.
• Les correctifs sont sortis le 21 octobre, vers 16 h à Paris : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Toute installation PHP qui sert des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est le plus élevé avec mod_php.
• Seule la mise à jour règle le problème, et il faut redémarrer PHP-FPM ou le serveur web ensuite. Les réglages de contournement réduisent l'exposition sans protéger complètement.
• PHP 8.1 et les versions antérieures ne reçoivent pas de correctif du projet : il faut un paquet de votre distribution, un backport à compiler soi-même ou une migration.

Que s'est-il passé avec la faille PHP ?

Les informations ont fuité avant la date prévue. Le 20 octobre, un message sur Hacker News, depuis supprimé, annonçait deux failles dans le cœur de PHP pour le 22 octobre. La société watchTowr a confirmé que la fuite était réelle, sans avoir découvert elle-même les failles. Le soir même, l'équipe de sécurité de PHP a prévenu qu'une version de sécurité sortirait le 21 octobre, en se réservant le droit de publier plus tôt si des détails devenaient publics ou si des attaques apparaissaient.

Le CERT-FR a publié son alerte avant les correctifs : il y cite les deux CVE, parle de versions 5.x à 8.x touchées et recommande surtout de désactiver le suivi de progression des envois et de bloquer les requêtes multipart. L'avis de sécurité de PHP, publié ensuite, est plus complet et plus prudent : à ses yeux, seule la mise à jour est une solution complète.

Quelles versions de PHP sont concernées ?

Les avis officiels détaillent les branches 8.2 à 8.5, pour lesquelles un correctif existe. Pour les versions plus anciennes, le CERT-FR parle de toutes les versions 5.x à 8.x, et le projet PHP ne publie pas de correctif. Considérez-les donc comme vulnérables tant qu'elles n'ont pas été corrigées par votre distribution.

Pour les branches abandonnées, l'équipe de sécurité de PHP a tout de même préparé des backports minimaux du code source pour PHP 7.4, 8.0 et 8.1, disponibles dans des branches dédiées du dépôt GitHub. Ils s'adressent à ceux qui compilent PHP eux-mêmes ou n'ont pas de fournisseur LTS. Les distributions et les fournisseurs LTS ont reçu les correctifs en avance : vérifiez les paquets proposés par votre éditeur.

Comment fonctionnent ces deux failles ?

PHP a publié les avis techniques avec les correctifs. Dans les deux cas, le problème vient de la façon dont un worker PHP gère sa mémoire quand une requête se termine de travers.

CVE-2026-109618 : une erreur de mémoire qui laisse des données invalides

Quand PHP manque de mémoire, il interrompt la requête par un saut brutal. Si cela arrive alors que les données internes de la requête ne sont qu'à moitié initialisées, le nettoyage de fin de requête peut les traiter comme valides. L'avis cite des requêtes multipart qui provoquent ce manque de mémoire tout en restant dans les limites apparentes de PHP : sans longueur déclarée utilisable, avec un nombre illimité d'en-têtes par partie, ou avec des champs imbriqués qui multiplient le travail. Une exécution de code complète a été validée sur Apache avec mod_php, avec les limites par défaut. PHP-FPM est jugé vulnérable d'après l'analyse du code, sans exploit complet démontré. D'après le suivi en direct de Precursor Security, la correction remplace ce saut brutal par une gestion plus douce du manque de mémoire, et l'analyse technique parle de quatre bugs répartis sur les deux CVE.

CVE-2026-109619 : un état global qui survit à la requête

Un worker PHP persistant garde des données globales (erreurs, session, objets, extensions) qui peuvent pointer vers de la mémoire appartenant à la requête précédente. Si une erreur fatale saute le nettoyage, la requête suivante traitée par le même worker peut lire ces données avant leur réinitialisation : c'est une utilisation de mémoire libérée. Deux voies sont confirmées : les traces de pile des erreurs fatales sous PHP 8.5, avec une exécution de code validée sur mod_php, et le suivi de progression des envois de fichiers, validé sur mod_php et PHP-FPM.

Pourquoi mod_php est-il le plus exposé ? Les directives de configuration appliquées par Apache s'exécutent avant l'initialisation de la requête, ce qui peut déclencher des messages d'erreur trop tôt. L'avis de PHP indique qu'une requête non authentifiée peut déclencher l'attaque avant l'exécution de tout code applicatif. Autrement dit, la sécurité de votre WordPress, de votre Magento ou de votre application maison ne change rien : la faille se trouve sous eux.

Que faire maintenant pour corriger la faille PHP ?

1. Savoir quelle version de PHP sert vos visiteurs

Ne vous fiez pas à php -v seul : la version en ligne de commande peut différer de celle qui sert le web. Vérifiez le composant réellement exposé et recensez aussi les PHP embarqués dans des panneaux de contrôle ou des logiciels tiers.

php -v
php-fpm8.3 -v
apache2ctl -M | grep -i php
dpkg -l 'php*' | awk '/^ii/ {print $2, $3}'
rpm -qa 'php*'

Le module php_module dans la liste d'Apache signale mod_php, le cas le plus exposé. Adaptez le nom du binaire FPM à votre version.

2. Installer la mise à jour

• Debian et Ubuntu : sudo apt update && sudo apt upgrade, puis vérifiez que le paquet contient le correctif. Si vous utilisez le dépôt d'Ondřej Surý, aucune date n'avait été annoncée au moment où nous avons relu les sources.
• RHEL, Rocky et AlmaLinux : sudo dnf upgrade 'php*'. Si vous utilisez le dépôt bénévole Remi, sachez que PHP a prévenu qu'il n'aurait pas de mise à jour le jour de la publication : passez par les paquets de la distribution ou compilez depuis les sources.
• Docker : récupérez l'image PHP officielle dès sa republication, reconstruisez vos images dérivées avec docker build --pull et redéployez. Un conteneur en cours d'exécution ne se met pas à jour tout seul. Nous n'avons pas pu confirmer que les images officielles étaient déjà republiées.
• Windows : les binaires de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sur la page de téléchargement de php.net.

3. Redémarrer, puis vérifier

Un paquet mis à jour sur le disque ne sert à rien tant que les anciens workers tournent. Redémarrez PHP-FPM ou Apache. Avec mod_php, un simple reload ou apachectl graceful ne suffit pas : faites un redémarrage complet.

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

• LiteSpeed : mettez à jour les paquets lsphp, puis arrêtez les processus avec sudo pkill lsphp.
• FrankenPHP : il embarque son propre PHP, donc apt et dnf ne le mettent pas à jour. Installez une nouvelle version ou une nouvelle image.
• Files d'attente et serveurs persistants : relancez-les aussi, par exemple php artisan queue:restart pour les files Laravel.

Les distributions corrigent souvent sans changer le numéro de version : lisez le journal des modifications du paquet plutôt que de vous fier à php -v.

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961(8|9)'
ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'

Comparez enfin l'heure de démarrage du processus maître PHP-FPM à celle de l'installation du paquet : un démarrage plus ancien signifie que le code non corrigé tourne encore. Sous Debian et Ubuntu, sudo needrestart -b -r l liste les services qui doivent être relancés.

Impossible de mettre à jour tout de suite ?

PHP le dit clairement : ces réglages réduisent l'exposition à certains chemins d'attaque, mais ne rendent aucune installation sûre. À n'utiliser qu'en attendant la mise à jour.

• Réduire la taille des requêtes : post_max_size = 8M si l'application n'a pas besoin d'envois de fichiers, 32M sinon, avec upload_max_filesize en dessous.
• Désactiver le suivi de progression : session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration du serveur, puis redémarrer tous les workers. Pas via ini_set() ni .user.ini.
• Sous PHP 8.5 : fatal_error_backtraces=0, puis redémarrage des workers.
• Poser memory_limit=-1 de façon non modifiable par les applications (par exemple avec php_admin_value). Cela retire un déclencheur, mais pas tous les échecs d'allocation, et peut peser sur la mémoire du serveur : préférez donc la mémoire par conteneur ou cgroup, en tuant seulement le worker concerné. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA.
• Bloquer les requêtes multipart sur le serveur frontal si l'application n'accepte aucun envoi de fichier, et limiter le nombre de champs, de parties et d'en-têtes.
• Retirer du web les applications PHP qui n'ont pas besoin d'être publiques, ou les placer derrière un VPN ou une liste d'IP autorisées.

Un pare-feu applicatif ou une protection comme celle de Cloudflare est un palliatif faible. Il ne voit que le trafic qui passe par lui et peut manquer des variantes. Vérifiez aussi que le serveur d'origine n'est pas joignable en direct, en contournant ce filtre.

PHP 8.1 ou plus ancien : que faire ?

Un comptage de bannières réalisé le 20 octobre recense environ 884 000 hôtes exposés qui annoncent PHP 8.1 ou une version plus ancienne, soit 59 % des quelque 1,5 million d'hôtes qui indiquent leur version. Ce sont des bannières, pas des systèmes confirmés vulnérables. Trois options, par ordre de préférence :

• Migrer vers une branche supportée, de préférence 8.3, 8.4 ou 8.5 plutôt que 8.2, qui sort du support le 31 décembre 2026.
• Installer le correctif de votre distribution ou de votre fournisseur LTS, en lisant le journal du paquet pour vérifier la présence des deux CVE.
• Sachez que certains correctifs de distribution ne sont pas garantis. D'après un guide d'application des correctifs, Ubuntu 22.04 (PHP 8.1) n'en reçoit un que si Canonical le rétroporte, et Debian 11 (PHP 7.4) n'est plus couvert que par l'offre payante ELTS, le support LTS gratuit s'étant arrêté le 31 août 2026.
• À défaut, compiler un des backports minimaux fournis par PHP pour les branches 7.4, 8.0 et 8.1, ou isoler le serveur derrière un VPN en attendant.

Comment savoir si votre serveur a été visé ?

Au moment où nous écrivons, des tentatives ont déjà été signalées avant même la publication des correctifs. D'après le suivi en direct de Precursor Security, Cloudflare a rapporté des attaques précoces dans la matinée du 21 octobre et Patchstack des tentatives chez ses partenaires d'hébergement. Huntress et watchTowr, eux, n'en avaient pas observé dans leurs environnements, et nous n'avons trouvé aucune confirmation de compromissions réussies. La société Sansec s'attendait à des attaques massives dans les quinze minutes suivant la publication. Un code d'exploitation circule, mais son fonctionnement n'est pas vérifié, et il peut contenir un logiciel malveillant : ne l'exécutez pas.

Voici ce que la liste de contrôle de Huntress recommande de surveiller, depuis le 20 octobre :

• des processus enfants suspects lancés par PHP (php-fpm, php-cgi, httpd, apache2) : shells, interpréteurs comme python ou perl, outils comme curl, wget ou nc ;
• des lignes de commande typiques d'un shell inversé (/dev/tcp/, fsockopen, mkfifo) ou de reconnaissance (whoami, id, uname -a) ;
• de nouveaux fichiers dans la racine web, des tâches cron ou planifiées inconnues, des comptes créés récemment.

Si vous trouvez quelque chose, isolez le serveur et conservez les journaux web et PHP avant de nettoyer. L'avis de PHP ajoute un point utile : des journaux propres ne prouvent pas que vous êtes sain. Activez log_errors avec error_reporting=E_ALL dans un environnement isolé et cherchez les erreurs fatales, les dépassements de délai et les avertissements survenus avant l'initialisation de la requête.

Notre avis : si vous gérez un VPS ou un serveur dédié, mettez à jour aujourd'hui, en commençant par ce qui est exposé sur Internet, et redémarrez les workers : c'est l'étape qu'on oublie. Ne comptez ni sur session.upload_progress.enabled=0 ni sur un pare-feu applicatif : PHP lui-même dit que la mise à jour est la seule vraie solution. Si vous êtes encore en PHP 8.1 ou plus ancien, ce correctif est le signal pour migrer plutôt que pour empiler des rustines.

Questions fréquentes

Mon site WordPress ou Magento est-il concerné ?

Oui, s'il tourne sur une version de PHP touchée : la faille se trouve dans PHP, pas dans le CMS. Mettre à jour WordPress, un plugin ou un thème ne la corrige pas. Il faut mettre à jour PHP sur le serveur.

Et sur un hébergement mutualisé ?

Vous ne contrôlez pas le serveur : la mise à jour revient à votre hébergeur. D'après le suivi de Precursor Security, cPanel a prévu des mises à jour de ses paquets ea-php74 à ea-php85, mais les délais dépendent de votre hébergeur. Demandez-lui s'il a déployé les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, et vérifiez dans votre espace client la version de PHP choisie pour votre site. Si elle est en 8.1 ou plus ancienne, passez à une version supportée dès que votre site le permet.

Les scripts en ligne de commande sont-ils concernés ?

L'avis de PHP vise les installations qui servent des requêtes web. Rien dans les sources consultées ne dit qu'un script lancé en ligne de commande soit exposé de la même manière, mais mettez à jour le PHP complet du serveur pour ne pas avoir de doute.

Faut-il désactiver le suivi de progression des envois en attendant ?

Oui si vous n'en avez pas besoin, c'est même recommandé après la mise à jour. Mais cela ne bloque que les voies d'attaque confirmées, pas les autres variantes. Un développeur du cœur de PHP a écrit que la seule mitigation est la mise à jour.

Un pare-feu applicatif ou Cloudflare suffit-il ?

Non. C'est un palliatif : il ne protège que le trafic qui le traverse et peut passer à côté de variantes. Il ne dispense pas de la mise à jour, surtout si votre serveur d'origine reste joignable en direct.

PHP 8.1 recevra-t-il un correctif ?

Pas du projet PHP. Certaines distributions et certains fournisseurs LTS proposent des correctifs rétroportés, et PHP a publié des backports minimaux de code source pour 7.4, 8.0 et 8.1. Le plus sûr reste de migrer vers une branche supportée.

Où trouver les informations officielles ?

Sur l'avis de sécurité de php.net, dans les avis GitHub de PHP pour la CVE-2026-109618 et la CVE-2026-109619, et dans l'alerte CERTFR-2026-ALE-014 du CERT-FR.