PHP s’est fait avoir, pas mes serveurs : deux RCE critiques en un jour – et je suis safe

🌐 Aussi en: English · Deutsch · Español

Le 21 octobre 2026, le projet PHP a publié quatre versions d’un coup – 8.5.12, 8.4.27, 8.3.36 et 8.2.35 – sans le petit discours habituel sur les « corrections de bugs ». Deux failles critiques, CVSS 9.2 chacune, exécution de code à distance sans authentification, et une phrase que tout admin devrait lire deux fois : « There are no complete mitigations, updating is the only safe choice. »

Les bugs sont dans PHP depuis très longtemps ; l’intéressant n’est pas une ligne de code fautive, mais la façon dont PHP fait le ménage derrière lui. Voici la version courte et geek.

🧨 Faille 1 : le parachute mémoire qui s’ouvre trop tôt

CVE-2026-109618. Quand une requête manque de mémoire, PHP ne se retire pas poliment : il saute directement dehors avec longjmp(). Si cela arrive alors que les données de la requête ne sont qu’à moitié initialisées, le nettoyage de fin de requête traite ces structures à moitié construites comme valides et travaille sur des déchets. Avec les bons déchets, c’est de l’exécution de code sous l’utilisateur du serveur web.

Le plus vicieux : on peut atteindre le manque de mémoire tout en restant dans les limites que PHP croit appliquer. Les envois multipart sans longueur exploitable passent sous post_max_size, les parties multipart peuvent porter un nombre illimité d’en-têtes qui coûtent bien plus de mémoire dans PHP que sur le réseau, et les champs de fichier vides ne comptent pas dans max_file_uploads. Le correctif supprime complètement longjmp() en cas de manque de mémoire.

👻 Faille 2 : l’état de la requête précédente hante la suivante

CVE-2026-109619. Un worker PHP sert de nombreuses requêtes à la suite. Certains états globaux – erreurs, sessions, données d’extensions – peuvent encore pointer vers la mémoire de la requête précédente après sa libération. Si la requête suivante y touche avant que PHP ne les réinitialise, on obtient un use-after-free classique. Déclencheurs confirmés : les backtraces d’erreurs fatales, nouveautés de PHP 8.5, et la progression d’upload des sessions.

🎯 Qui est concerné

• Tout ce qui sert des requêtes web : PHP-FPM, Apache avec mod_php (exploit confirmé, risque le plus élevé), php-cgi, FrankenPHP, LiteSpeed.
• Pour PHP-FPM, le chemin par la progression d’upload des sessions a été validé comme RCE ; le chemin par manque de mémoire est « vulnérable selon l’analyse du code ».
• Les branches 8.2 à 8.5. PHP 8.1 et antérieur ne reçoivent aucun correctif – si vous l’utilisez encore, voici votre signal. PHP 8.2 lui-même arrive en fin de vie le 31 décembre 2026.

🩹 Rustines si vous ne pouvez vraiment pas mettre à jour aujourd’hui

• session.upload_progress.enabled = 0 (et le laisser désactivé ensuite si vous ne l’utilisez pas), plus fatal_error_backtraces = 0 sous PHP 8.5 – redémarrer tous les workers.
• Limiter la taille des requêtes, les parties multipart et les en-têtes au niveau du reverse proxy ; bloquer complètement le multipart là où l’application n’a pas besoin d’uploads.
• Une limite mémoire par conteneur ou cgroup – pas RLIMIT_AS/RLIMIT_DATA, qui déclenchent justement le chemin vulnérable.
• Tout cela réduit le risque. Rien de cela ne ferme la faille. Les avis de sécurité le disent eux-mêmes.

🐳 Le piège des conteneurs – le prix des couches

Les conteneurs ont un inconvénient qu’une journée comme celle-ci rend douloureusement visible. Une image officielle n’est pas construite d’un bloc ; c’est une pile de couches, et chaque couche appartient à quelqu’un d’autre : en bas une base Debian, au-dessus l’image officielle php, au-dessus encore l’image wordpress ou nextcloud. Un correctif de PHP doit remonter cette chaîne, étage par étage :

1. Le projet PHP publie la version (ici : le 21 octobre dans l’après-midi, heure européenne).
2. Les mainteneurs de l’image officielle php mettent à jour leurs fichiers de build, un relecteur les fusionne, et la ferme de build reconstruit chaque variante – fpm, apache, cli, alpine, debian, pour chaque architecture. C’était environ une heure après la publication.
3. Ce n’est qu’ensuite que les images wordpress et nextcloud peuvent être reconstruites sur la nouvelle base, là encore pour chaque tag et chaque architecture – sous le même tag qu’avant. Cette étape est arrivée des heures plus tard, pas des minutes.
4. Et ce n’est qu’alors que mon passage de mise à jour peut récupérer la nouvelle image et redémarrer les pods.

Sur un serveur classique, on tape apt upgrade dès que la distribution livre le paquet – les distributions reçoivent les correctifs à l’avance et publient en général en quelques heures. Avec des conteneurs, on ne peut pas simplement mettre à jour PHP dans l’image : le conteneur est fait pour être remplacé, pas rapiécé, et ce qu’on modifie à la main disparaît au prochain redémarrage. On attend ceux qui construisent les couches. La plupart du temps, c’est un avantage – des images reproductibles et testées, une mise à jour se résume à un changement d’image, un retour arrière au tag précédent. Un jour de RCE critique, c’est une salle d’attente.

Deux conséquences pratiques. D’abord : le tag ne dit rien. wordpress:7.1.3-php8.4-fpm était le même tag avant et après le correctif, donc vérifiez la version de PHP dans l’image : docker exec … php -v ou kubectl exec … -- php -r "echo PHP_VERSION;" doit afficher 8.4.27 / 8.5.12 (ou 8.3.36 / 8.2.35) – puis retirez l’image et redémarrez le pod. Ensuite : prévoyez un plan pour l’attente. C’est à cela que servent les rustines plus haut.

🏠 Et sur mes propres serveurs ?

Oui, concernés – tous les trois. Le blog fait tourner WordPress dans l’image officielle wordpress:…-php8.4-fpm, les deux serveurs Nextcloud l’image officielle nextcloud:…-fpm avec PHP 8.5 : PHP-FPM partout, derrière nginx. Et les deux chemins confirmés étaient ouverts : la progression d’upload des sessions est activée par défaut, et sous PHP 8.5 les backtraces d’erreurs fatales aussi. Le reste de l’installation rend une attaque plus difficile – pas de mod_php, des limites de taille à l’ingress, une limite mémoire pour chaque pod, SELinux autour de chaque conteneur –, mais plus difficile ne veut pas dire impossible, et rien de cela n’est un correctif.

L’attente. Le PHP corrigé était sorti, les images corrigées non (voir le piège des conteneurs plus haut). Pour ces heures-là, j’ai donc pris la voie douce de la liste des rustines : session.upload_progress.enabled = Off sur les trois serveurs, et sur les deux Nextcloud en PHP 8.5 aussi fatal_error_backtraces = Off. Cela ferme exactement les deux chemins que les avis ont confirmés comme exploitables sous PHP-FPM, et aucune des deux applications n’utilise ces fonctions – WordPress n’utilise pas du tout la progression d’upload, Nextcloud envoie les gros fichiers par morceaux via JavaScript. Les sites sont restés en ligne. Ce n’est pas un correctif : le chemin par manque de mémoire reste théoriquement ouvert tant que le PHP corrigé ne tourne pas. Les deux réglages restent désactivés après la mise à jour : l’avis recommande de laisser la progression d’upload coupée là où elle ne sert pas – une fonction que personne n’utilise ne peut pas ouvrir la prochaine faille –, et les backtraces d’erreurs fatales apportent peu ici, car Nextcloud écrit de toute façon ses erreurs avec la pile d’appels dans son propre journal.

État : tout est propre. L’image WordPress reconstruite avec PHP 8.4.27 était disponible à 20h06 (heure de Paris, 18h06 UTC), environ quatre heures après la publication de PHP ; l’image Nextcloud reconstruite avec PHP 8.5.12 a suivi à 20h25 (18h25 UTC). Le blog tourne avec le PHP corrigé depuis 20h26, les deux serveurs Nextcloud depuis 20h31 et 20h36 – vérifié dans chaque conteneur, pas en regardant le tag, ainsi que les deux réglages de rustine, qui restent désactivés. De la publication au dernier serveur corrigé : environ quatre heures et demie, passées surtout à attendre les images. Aucune trace d’attaque dans les journaux, et les contrôles d’intégrité de WordPress (cœur et toutes les extensions) et de Nextcloud sont propres. Je suis safe. 🐘✅

⏱️ TL;DR

Deux RCE critiques sans authentification dans PHP lui-même, toutes les SAPI web, aucun vrai contournement. Mettez à jour vers 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 maintenant – paquets de distribution, images de conteneurs, panneau d’hébergement, peu importe. Et si votre hébergeur gère PHP pour vous : demandez-lui aujourd’hui s’il l’a fait. apt upgrade n’a jamais été aussi littéral. 🐘🔐

Sans garantie : cet article décrit ce que j’ai constaté et fait sur mes propres serveurs, au mieux de mes connaissances le jour de sa rédaction. Je n’assume aucune responsabilité pour vos systèmes – ni pour la mise à jour, ni pour les rustines décrites ici, qui ne protègent explicitement pas complètement. Le seul vrai correctif est la version corrigée de PHP ; consultez les avis officiels pour votre installation.

Sources : avis de sécurité PHP du 21/10/2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.