Deux RCE critiques dans PHP : qui est exposé et dans quel ordre patcher

Le 21 octobre 2026, le projet PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35, avec un avis de sécurité sans détour : mettez à jour maintenant. Ces versions corrigent deux vulnérabilités critiques qui peuvent permettre une exécution de code à distance sans authentification, et l'avis considère comme exposée toute installation PHP qui sert des requêtes web : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Si vous faites tourner Laravel, WordPress ou n'importe quoi d'autre sur PHP, le problème se situe dans le runtime sous votre code, pas dans votre code. Votre application n'a pas besoin d'avoir le moindre défaut pour être concernée.

Les deux bugs

CVE-2026-109618 concerne la gestion du manque de mémoire. Un échec d'allocation peut interrompre PHP alors que des données internes de la requête ne sont qu'à moitié initialisées, et le nettoyage de fin de requête peut ensuite traiter ces données incomplètes comme valides. L'avis GitHub précise que plusieurs chemins d'analyse des uploads multipart peuvent atteindre cet état de mémoire épuisée alors que la requête semble respecter ses limites. CVE-2026-109619 concerne un état périmé : un objet appartenant à une requête peut survivre à la mémoire qui le porte, et la requête suivante traitée par le même worker peut s'en servir avant que l'initialisation normale ne le remette à zéro.

Le tracker tiers pwn.watch appelle ce duo « PHP2Shell », note les deux failles CVSS 9.2 et indique que les détails ont fuité en avance, avant la fin de l'embargo. Toujours selon ce tracker, des tentatives d'exploitation ont été vues avant et après le correctif, watchTowr et AWS signalent des scans actifs, et des fabricants d'appliances comme QNAP préparaient encore leurs correctifs. Ce sont les affirmations du tracker ; pour savoir quoi installer, c'est l'avis de php.net qui fait foi.

Les configurations les plus exposées

Le risque n'est pas le même pour toutes les interfaces serveur. L'avis GitHub explique pourquoi : mod_php exécute toujours l'arrêt de la requête, même quand son démarrage a échoué. Un manque de mémoire pendant l'analyse du corps de la requête conduit donc à traiter un état invalide avant la moindre ligne de code applicatif, et un exploit fonctionnel y a été démontré. PHP-FPM, lui, termine le processus enfant quand le démarrage échoue, ce qui le retire du pool ; FPM reste vulnérable d'après l'analyse du code source, mais aucun exploit complet n'a été montré. FrankenPHP est probablement vulnérable de la même façon que mod_php, et le LSAPI de LiteSpeed se comporte comme FPM.

Trouver chaque PHP, puis patcher dans l'ordre

En règle générale, un serveur peut héberger plusieurs PHP, et php -v dans un terminal donne la version du binaire en ligne de commande, qui n'est pas toujours celle qu'utilise le serveur web. Vérifiez chaque endroit où une version peut se cacher : la CLI, le service FPM, chaque image Docker que vous construisez ou récupérez, et le sélecteur de version PHP d'un panneau d'hébergement.

# the command-line PHP (may differ from the web one)
php -v
# the PHP inside a container image you deploy
docker run --rm your-image:tag php -v

Pour la version que le serveur web exécute réellement, un fichier temporaire répond en une requête. Supprimez-le aussitôt après.

<?php
echo PHP_VERSION, ' ', PHP_SAPI;

Tout ce qui est en dessous de 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 est touché. Les distributions Linux et les fournisseurs de support long terme ont reçu les correctifs à l'avance : regardez d'abord les paquets de votre fournisseur. L'avis note que rpms.remirepo.net, maintenu par des bénévoles, n'aurait pas les mises à jour le jour de la sortie, et propose à la place les paquets de la distribution ou une compilation depuis les sources. PHP 8.1 et les versions plus anciennes ne reçoivent plus rien du projet PHP ; certains fournisseurs rétroportent, et l'équipe sécurité a publié des rétroportages minimaux pour 7.4, 8.0 et 8.1 à l'intention de ceux qui compilent eux-mêmes.

Après la mise à jour, redémarrez tous les workers PHP. Un pool FPM qui tourne depuis longtemps ou un worker FrankenPHP garde l'ancien binaire en mémoire tant qu'il n'est pas redémarré.

Ce que font les mesures d'atténuation, et ce qu'elles ne font pas

L'avis est clair sur ce point : la mise à jour est la seule solution complète, et les mesures qu'il liste réduisent l'exposition sur des chemins précis sans rendre une installation sûre. Pour le bug de mémoire, elles comprennent : memory_limit=-1 là où les applications ne peuvent pas le surcharger (php_admin_value dans le pool FPM ou la config Apache), un post_max_size bas (8M sans upload, 32M avec, et upload_max_filesize en dessous), des limites au niveau du serveur web ou du proxy sur la taille de la requête, le nombre de champs, les parties multipart, les en-têtes et l'imbrication, et une limite mémoire de conteneur ou de cgroup plutôt que RLIMIT_AS ou RLIMIT_DATA, qui peuvent provoquer justement l'échec d'allocation en cause. Pour le bug d'état périmé : session.upload_progress.enabled=0 dans php.ini ou la config du pool (pas via ini_set() ni .user.ini) avec tous les workers redémarrés, fatal_error_backtraces=0 en 8.5, la suppression des réglages par requête invalides ou obsolètes, et la correction des erreurs fatales et des timeouts qu'un attaquant peut déclencher.

L'étape concrète d'aujourd'hui : listez chaque serveur, image de conteneur et compte d'hébergement qui fait tourner PHP, notez la version servie par chacun, et mettez à jour ceux qui sont sous les versions corrigées avant de toucher au moindre réglage. Source : php.net, avis de sécurité du 21 octobre 2026.