CVE-2026-109618 : exécution de code à distance dans PHP par corruption en cas de manque de mémoire

Ce qui se passe mal, au niveau des informations de l’éditeur

Sur oss-security, Jakub Zelenka a écrit que PHP interrompt le traitement des requêtes via longjmp() en cas d’erreur de manque de mémoire ; une allocation échouée peut interrompre l’initialisation alors qu’un état de requête incomplet est déjà accessible, et l’arrêt de la requête peut alors accéder à cet état invalide, permettant potentiellement une exécution de code à distance. La présentation de la PHP Foundation concorde : si une requête atteignait memory_limit au mauvais moment, des données partiellement initialisées pouvaient subsister et être ensuite considérées comme valides.

Nous ne publions rien au-delà de ce mécanisme. Nous ne décrivons pas comment provoquer l’erreur mémoire.

Ce qui a été démontré

• oss-security : une exécution de code à distance sans authentification a été démontrée via HTTP contre Apache mod_php, avant l’exécution du code applicatif. L’analyse du code source indique aussi une exposition de FPM, mais aucun exploit FPM complet n’a été démontré.
• PHP Foundation : une exécution de code à distance complète a été démontrée sur Apache mod_php avec les réglages par défaut, avant l’exécution du code applicatif. Sur PHP-FPM, une RCE a été confirmée via des chemins de code applicatifs.
• Expel, citant PHP : la démonstration mod_php pour cette CVE fonctionnait avec les limites par défaut de PHP pour les entrées et la mémoire.
• L’avis de l’Université de Toronto indique que des attaquants pourraient provoquer cet état avec des requêtes multipart forgées respectant en apparence les limites de PHP. Nous ne développons pas cette phrase en mode d’emploi.

Impact

Une exploitation réussie signifie une exécution de code à distance sans authentification avec les droits du compte système du worker PHP. Wiz et Cloudflare citent aussi des plantages et la divulgation de mémoire du processus. La portée dépend du build, des extensions et de l’architecture du serveur ; selon l’Université de Toronto, la fiabilité varie, et PHP a validé une RCE complète. Les sources examinées ne contiennent aucune affirmation fiable du type « fonctionne partout » – et aucune raison d’attendre pour corriger.

Correction

Mettez à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ou plus récent et redémarrez les workers qui servent le trafic. Selon oss-security, la mise à jour est la seule remédiation complète. Les réglages provisoires de PHP, dont memory_limit=-1 et un post_max_size bas, sont incomplets : même sans limite mémoire contrôlable, une erreur d’allocation sous-jacente peut atteindre le chemin vulnérable. Selon Tanium, l’entrée NVD a été publiée le 21 octobre 2026 avec le statut « Undergoing Analysis ». Utilisez l’avis PHP comme source opérationnelle tant que la NVD n’a pas rattrapé son retard.

Exposition selon le type de serveur, d’après l’avis complet de PHP

L’avis GitHub explique pourquoi le risque varie selon le SAPI. Le point décisif : PHP exécute-t-il encore le nettoyage de fin de requête quand le démarrage de la requête a échoué ?

Pourquoi les limites d’upload ne plafonnent pas la mémoire

Selon l’avis, une requête de formulaire multipart peut épuiser la mémoire de PHP tout en semblant rester sous les limites configurées. En résumé : un corps sans longueur exploitable peut passer le contrôle post_max_size ; le nombre d’en-têtes dans une partie n’est pas limité et ils occupent plus de place en mémoire que sur le réseau ; les champs de fichier vides ne comptent pas dans max_file_uploads, mais PHP crée quand même leurs tableaux d’upload. Le code applicatif peut aussi atteindre cet état si une saisie utilisateur pilote une grosse allocation. Nous restons au niveau publié par PHP et ne décrivons pas comment fabriquer une telle requête.

Ce que le correctif change dans PHP

En cas de manque de mémoire, PHP ne saute plus hors du chemin de code en cours. Une erreur « douce » est levée au prochain point sûr du moteur ; si la consommation atteint un second seuil plus élevé, le processus se termine immédiatement. memory_limit continue de fonctionner et le nettoyage ne voit plus d’état à moitié construit.

Durcissement toujours utile après le correctif

Selon PHP, ces mesures réduisent le risque d’arrêts brutaux et de déni de service même sur une version corrigée. Elles ne remplacent pas la mise à jour.

• Limiter la taille décodée des requêtes au serveur web ou au proxy, indépendamment de post_max_size.
• Réduire max_input_nesting_level et plafonner max_input_vars, le nombre de parties multipart, d’en-têtes par partie et d’uploads.
• Si une application ou une route n’accepte jamais d’upload ni de formulaire multipart, refuser les requêtes multipart en bordure avant PHP. Beaucoup d’API de frameworks qui ne prennent que du JSON le permettent sans risque.
• Les limites mémoire de conteneur ou de cgroup (memory.max) ne remplacent memory_limit qu’en partie. Tuer un conteneur entier tue aussi le maître FPM et tous les workers, sauf si chaque worker a son propre groupe.
• Ne pas utiliser RLIMIT_AS ni RLIMIT_DATA comme plafond mémoire : selon PHP, ils font échouer l’allocation précisément de la manière qui atteint la faille.