Des versions corrigées de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont été publiées, ainsi que des correctifs pour les versions non prises en charge de PHP 7.4, PHP 8.0 et PHP 8.1 (les versions vulnérables de 5.4 à 7.3 ne reçoivent pas de correctifs), dans lesquelles deux vulnérabilités critiques ont été corrigées :
- CVE-2026-109618 — exécution de code à distance, causée par le fait qu'une fois la mémoire libre du processus épuisée, le gestionnaire de pénurie de mémoire via l'exécution de la fonction longjmp() peut interrompre l'interpréteur PHP dans un état où seules certaines structures internes liées au traitement de la requête sont initialisées. Par la suite, la fonction de fin de traitement de la requête accède à ces structures comme si elles étaient déjà initialisées, alors que la mémoire pour elles n'a pas été allouée.
Le principal vecteur d'attaque est la manipulation des requêtes multipart pour créer des conditions d'épuisement de la mémoire disponible au processus. Pour contourner la limite post_max_size, l'en-tête Content-Length peut ne pas être spécifié et un nombre énorme d'en-têtes HTTP peut être transmis. Des attaques ciblées sur des opérations spécifiques dans des applications PHP consommant excessivement de la mémoire sont également possibles. La présence d'un exploit est confirmée pour mod_php, car il appelle la fonction shutdown() même en cas d'échec. PHP-FPM, en cas d'échec, termine le processus enfant, ce qui complique l'exécution de l'attaque, mais ne l'exclut pas théoriquement.
- CVE-2026-109619 — exécution de code à distance, causée par un accès à la mémoire après sa libération en raison d'un nettoyage incorrect de l'état global associé à une requête spécifique. En cas d'interruption de la requête due à une erreur fatale, un dépassement de délai ou un épuisement de la mémoire, l'état global peut ne pas être réinitialisé et les pointeurs peuvent rester actifs, malgré la libération de la mémoire à laquelle ils font référence. Lors du traitement de la requête suivante dans le même processus, un accès par le pointeur restant à l'ancien état global peut se produire.
L'exploitation peut impliquer la création de conditions d'épuisement de la mémoire disponible lors du traitement de requêtes multiparties dans le code pour indiquer la progression du téléchargement (session.upload_progress). Dans ce cas, le gestionnaire fatal_error_backtraces dans PHP 8.5 est mentionné comme le principal et confirmé vecteur d'attaque, qui ne réinitialise pas l'état de la trace lors de l'achèvement. Dans le premier cas, l'attaque est possible sur mod_php et PHP-FPM, tandis que dans le second, uniquement sur mod_php. Une possibilité d'attaque non confirmée est également mentionnée dans les configurations où des directives peuvent entraîner l'affichage d'avertissements à un stade précoce du traitement d'une requête (par exemple, avertissements concernant l'utilisation de paramètres obsolètes).
Il a été déclaré que le blocage complet des vulnérabilités n'est possible que par l'installation d'une mise à jour. Les mesures suivantes permettent de réduire la probabilité d'une attaque réussie, mais ne rendent pas le système complètement sûr :
- Définir dans php.ini le paramètre «memory_limit=-1», ce qui complique la possibilité pour l'attaquant de contrôler l'épuisement des limites de mémoire.
- Définir le paramètre «post_max_size = 8M» si le téléchargement de gros fichiers n'est pas nécessaire. La valeur du paramètre «upload_max_filesize» doit être inférieure à celle de «post_max_size».
- Fixer une limite de consommation de mémoire au niveau du système, via cgroup memory.max ou des paramètres de consommation mémoire du conteneur, mais pas via les limites système RLIMIT_AS et RLIMIT_DATA, qui ne font que provoquer un appel problématique à longjmp().
- Si la performance n'est pas importante, vous pouvez limiter le nombre de requêtes traitées par un seul processus de travail via pm.max_requests=1 dans PHP-FPM et MaxRequestsPerChild dans Apache httpd.
- Définir au niveau de php.ini ou de la configuration de serveurs (pas via ini_set() ou FPM .user.ini, car le paramètre doit s'appliquer avant le début du traitement de la requête) le paramètre «session.upload_progress.enabled=0.
- Lors de l'utilisation de PHP 8.5, il convient de définir le paramètre «fatal_error_backtraces=0».
- Supprimer les configurations obsolètes ou incorrectes liées à des requêtes individuelles (telles que assert.* et chemins incorrects dans open_basedir), qui entraînent l'affichage de messages de diagnostic avant l'initialisation.
- Résoudre dans le code PHP les situations entraînant des délais d'attente et des erreurs fatales, par exemple, liées aux échecs des gestionnaires de callback et au traitement des téléchargements.
- Pour bloquer la première vulnérabilité dans le code des anciennes versions de PHP, il est possible de remplacer l'appel à longjmp() dans le gestionnaire d'épuisement de mémoire par _exit().
- De plus, il est recommandé de réduire la valeur du paramètre max_input_nesting_level dans php.ini et de bloquer les requêtes multipart, comme cela a été montré dans l'annonce préalable.
Le statut de la correction des vulnérabilités dans les distributions peut être évalué sur les pages suivantes : Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Annexe 1 : Les vulnérabilités ont été identifiées grâce à des modèles d'IA GPT‑5.6 et Gemini 4 Argon. OpenAI a publié un outil php2shell-checker pour vérifier l'exposition des sites et des fichiers exécutables locaux aux vulnérabilités, mais cet outil ne vérifie que le numéro de version de PHP renvoyé par le serveur HTTP ou la commande « php -v », sans analyse détaillée.
Annexe 2 : L'auteur du prototype d'exploit utilisant la vulnérabilité causée par le double libération de mémoire (double-free) a déclaré que le problème n'est toujours pas corrigé dans la version PHP 8.5.12 et que l'exploit continue de fonctionner. Auparavant, les représentants de PHP avaient indiqué que cette vulnérabilité n'était pas liée aux corrections à venir et ne constituait pas un problème réel. L'auteur de l'exploit a cependant affirmé qu'il s'agissait d'une vulnérabilité complètement différente.
Source : opennet.ru
