{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"D\u00e9tails des vuln\u00e9rabilit\u00e9s critiques en PHP r\u00e9v\u00e9l\u00e9s et mises \u00e0 jour correctives publi\u00e9es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des versions corrig\u00e9es de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ont \u00e9t\u00e9 publi\u00e9es, 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\u00e9rables de 5.4 \u00e0 7.3 ne re\u00e7oivent pas de correctifs), dans lesquelles deux vuln\u00e9rabilit\u00e9s critiques ont \u00e9t\u00e9 corrig\u00e9es :<\/p>\n
\n
CVE-2026-109618 \u2014 ex\u00e9cution \u00e0 distance de code caus\u00e9e par l'\u00e9puisement de la m\u00e9moire libre disponible pour le processus, o\u00f9 le gestionnaire de p\u00e9nurie de m\u00e9moire, en ex\u00e9cutant la fonction longjmp(), peut interrompre l'interpr\u00e9teur PHP dans un \u00e9tat o\u00f9 seules certaines structures internes li\u00e9es au traitement de la requ\u00eate sont initialis\u00e9es. Par la suite, la fonction de terminaison du traitement de la requ\u00eate acc\u00e8de \u00e0 ces structures comme si elles \u00e9taient d\u00e9j\u00e0 initialis\u00e9es, bien que la m\u00e9moire ne leur soit pas attribu\u00e9e.\n
Le principal vecteur d'attaque est la manipulation des requ\u00eates multipart pour cr\u00e9er des conditions d'\u00e9puisement de la m\u00e9moire disponible au processus. Pour contourner la limite post_max_size, l'en-t\u00eate Content-Length peut ne pas \u00eatre sp\u00e9cifi\u00e9 et un nombre \u00e9norme d'en-t\u00eates HTTP peut \u00eatre transmis. Des attaques cibl\u00e9es sur des op\u00e9rations sp\u00e9cifiques dans des applications PHP consommant excessivement de la m\u00e9moire sont \u00e9galement possibles. La pr\u00e9sence d'un exploit est confirm\u00e9e pour mod_php, car il appelle la fonction shutdown() m\u00eame en cas d'\u00e9chec. PHP-FPM, en cas d'\u00e9chec, termine le processus enfant, ce qui complique l'ex\u00e9cution de l'attaque, mais ne l'exclut pas th\u00e9oriquement. <\/p>\n
CVE-2026-109619 \u2014 ex\u00e9cution \u00e0 distance de code caus\u00e9e par un acc\u00e8s \u00e0 la m\u00e9moire apr\u00e8s sa lib\u00e9ration en raison d'un nettoyage incorrect de l'\u00e9tat global li\u00e9 \u00e0 une requ\u00eate sp\u00e9cifique. En cas d'interruption de la requ\u00eate en raison d'une erreur fatale, d'un d\u00e9passement de d\u00e9lai ou d'un manque de m\u00e9moire, l'\u00e9tat global peut ne pas \u00eatre r\u00e9initialis\u00e9, et les pointeurs peuvent rester actifs, m\u00eame apr\u00e8s la lib\u00e9ration de la m\u00e9moire vers laquelle ils pointent. Lors du traitement d'une requ\u00eate suivante dans le m\u00eame processus, l'acc\u00e8s par le pointeur restant \u00e0 l'ancien \u00e9tat global peut se produire.\n
L'exploitation peut impliquer la cr\u00e9ation de conditions d'\u00e9puisement de la m\u00e9moire disponible lors du traitement de requ\u00eates multiparties dans le code pour indiquer la progression du t\u00e9l\u00e9chargement (session.upload_progress). Dans ce cas, le gestionnaire fatal_error_backtraces dans PHP 8.5 est mentionn\u00e9 comme le principal et confirm\u00e9 vecteur d'attaque, qui ne r\u00e9initialise pas l'\u00e9tat de la trace lors de l'ach\u00e8vement. 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\u00e9 d'attaque non confirm\u00e9e est \u00e9galement mentionn\u00e9e dans les configurations o\u00f9 des directives peuvent entra\u00eener l'affichage d'avertissements \u00e0 un stade pr\u00e9coce du traitement d'une requ\u00eate (par exemple, avertissements concernant l'utilisation de param\u00e8tres obsol\u00e8tes).<\/p>\n<\/ul>\n
Il a \u00e9t\u00e9 d\u00e9clar\u00e9 que le blocage complet des vuln\u00e9rabilit\u00e9s n'est possible que par l'installation d'une mise \u00e0 jour. Les mesures suivantes permettent de r\u00e9duire la probabilit\u00e9 d'une attaque r\u00e9ussie, mais ne rendent pas le syst\u00e8me compl\u00e8tement s\u00fbr :<\/p>\n
\n
La d\u00e9finition de la directive dans php.ini \u00abmemory_limit=-1\u00bb, ce qui complique la possibilit\u00e9 pour un attaquant de contr\u00f4ler l'\u00e9puisement des limites de m\u00e9moire.\n
La d\u00e9finition de la directive \u00abpost_max_size=8M\u00bb, \u00e0 moins qu'il ne soit n\u00e9cessaire de t\u00e9l\u00e9charger de gros fichiers. La valeur de la directive \u00abupload_max_filesize\u00bb doit \u00eatre inf\u00e9rieure \u00e0 celle de \u00abpost_max_size\u00bb.\n
Fixer une limite de consommation de m\u00e9moire au niveau du syst\u00e8me, via cgroup memory.max ou des param\u00e8tres de consommation m\u00e9moire du conteneur, mais pas via les limites syst\u00e8me RLIMIT_AS et RLIMIT_DATA, qui ne font que provoquer un appel probl\u00e9matique \u00e0 longjmp().\n
Si la performance n'est pas importante, vous pouvez limiter le nombre de requ\u00eates trait\u00e9es par un seul processus de travail via pm.max_requests=1 dans PHP-FPM et MaxRequestsPerChild dans Apache httpd.\n