PHP 8.5, 8.4, 8.3, 8.2 : deux RCE critiques sans authentification, patchs disponibles
Sommaire
En bref
- Deux failles RCE non authentifiées affectent PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 et versions antérieures : l'une via corruption OOM, l'autre via état global obsolète.
- Les versions patché sont disponibles depuis le 21 octobre 2026 à 14h00 UTC ; mod_php est le vecteur d'attaque principal (RCE avant l'exécution du code applicatif).
- Des preuves de concept circulent sur Twitter et sont utilisées pour des attaques réelles en temps réel ; plusieurs grandes organisations (DigiD.nl, RTL, parlement néerlandais) ont fermé leurs sites.
- Mitigations partielles : désactiver session.upload_progress, bloquer les requêtes multipart au niveau du serveur web, arrêter les instances en attente du patch.
Ce que dit la source
La PHP Security Team a annoncé deux vulnérabilités RCE critiques (CVSS 9.2 selon PHP, 10.0 selon WatchTowr) touchant toutes les installations PHP traitant des requêtes web. La première (CVE-2026-109618, RCE via OOM corruption) exploite une défaillance du gestionnaire de mémoire insuffisante qui laisse des données de requête partiellement initialisées en mémoire, interprétées à tort comme valides au cleanup. La seconde (CVE-2026-109619, RCE via état global obsolète) réutilise un état interne dont la mémoire de secours a été libérée, exploitable par une requête suivante sur le même worker avant la réinitialisation. L'équipe considère mod_php comme le vecteur principal : une requête non authentifiée peut déclencher l'attaque avant que n'importe quel code applicatif s'exécute. Les versions corrigées (8.5.12, 8.4.27, 8.3.36, 8.2.35) ont été livrées le 21 octobre à 14h00 UTC, ainsi que des backports minimaux pour 7.4, 8.0, 8.1 à partir du code source.
- Le SAPI principal à risque : mod_php (aussi PHP-FPM, Apache, php-cgi, FrankenPHP, LiteSpeed, mais mod_php offre le chemin d'attaque le plus direct)
- Deux CVE distincts : CVE-2026-109618 (OOM) et CVE-2026-109619 (stale global state), demandent des mitigations différentes
- Mitigations non-complètes avant patch : désactiver session.upload_progress au niveau php.ini ou FPM (non via ini_set), définir memory_limit=-1 en admin, réduire post_max_size, bloquer les multipart au niveau serveur web ou proxy
- PHP 8.1 et antérieurs : plus de mises à jour officielles de la fondation, sauf backports source fournis ; vérifier auprès du distributeur Linux ou vendor LTS
- Les deux failles affectent PHP 8.0+ de manière rétrospective ; PHP 8.1 et 8.2 ne recevront plus de mises à jour officielles après cette correction si elles sortent du support
- Preuves de concept publiées sur Twitter et partagées en privé dès les heures suivant l'avis ; attaques en cours documentées par Cloudflare et autres
- Cloudflare a proposé une mitigation WAF (free et paid), Alpine Linux a pré-livré les patches, de grandes organisations (DigiD.nl, RTL, parlement NL) ont fermé leurs services en prévention
Dans les commentaires
Débat justifié mais intense : la majorité des commentateurs considère cette faille parmi les pires jamais découvertes en raison de sa trivialité d'exploitation (injection d'URL selon la vidéo en circulation) et de la capacité immédiate des LLM à automatiser les attaques. Peu de désaccord sur la gravité elle-même ; le débat porte sur la meilleure stratégie tactique (attendre le patch avec mitigations vs. éteindre les services immédiatement).
- Un commentateur (bwoebi), identifié comme membre de l'équipe de release PHP, explique que les patches ne sont pas encore disponibles au moment du fil (13+ heures après l'annonce) car les responsables de release dormaient, et reconnaît l'absence d'intervalle de latence entre la fuite vidéo et la publication du PoC sur Twitter.
- Plusieurs commentaires soulignent que les mitigations INI seules (session.upload_progress, file_uploads) ne suffisent pas : un manager PHP a confirmé sur Reddit que seul un patch résout entièrement le problème.
- Un commentateur (nr378) argue que si le PoC circule à grande échelle et que les patches ne sont pas encore disponibles, il est raisonnable de supposer que la plupart des sites PHP majeurs sont déjà compromis.
- Quelques tentatives de mitigation web server (réwrite rules Apache pour bloquer multipart) sont décrites, mais vérifiées avec prudence ; consensus que c'est mieux que rien mais loin d'être une protection complète.
- VPS et hébergeurs mutualisés évoqués comme des amplificateurs potentiels du risque vu la concentration d'instances LAMP non maintenues.
Notre lecture
Ceci n'est pas un exercice : deux RCE sans authentification avec PoC public et exploits activement automatisés pendant que les patches se mettaient en place. Pour toute infra PHP en production, l'arrêt de service jusqu'au patch était justifié. Même au-delà du patch, assumer une compromission probable des instances non patchées depuis la fuite : changements de secrets, audit des logs, relance saine exigée. Les mitigations proposées (memory_limit, post_max_size, blocage multipart, desactivation session.upload_progress) réduisent l'exposition mais ne supprimaient pas le risque. Le timing d'announcement-vs-release fut maladroit (PoC en circulation avant les patches disponibles), mais le scénario reflète aussi une réalité : coordonner un patch simultané à l'échelle mondiale sur des centaines de milliers d'installations n'est pas trivial. Courts délais pour vérifier que votre infrastructure PHP est à jour et que aucune machine n'a redémarré avec une ancienne version entre l'annonce et le patch.