Comment nous avons éliminé la vulnérabilité CVE-2026-111497 dans neuf versions de PHP

Principaux enseignements

• Le support à vie proposé par TuxCare pour PHP sous Windows, versions 5.2 à 8.2, n'est pas concerné par la vulnérabilité CVE-2026-111497.
• Aucune mise à jour n'est nécessaire, car les versions de TuxCare ne contiennent pas de code Brotli et leur libcurl ne négocie jamais Brotli.
• Les analyses binaires, les vérifications des fonctionnalités de libcurl, les tests HTTP en temps réel et un test de chargement latéral de DLL ont tous confirmé ce résultat.
• Les versions Windows de php.net en amont, à partir de PHP 8.2.31, intègrent Brotli et nécessitent les versions recompilées par php.net le 26 octobre.

La faille CVE-2026-111497 a mis en évidence une vulnérabilité grave dans le décodeur Brotli utilisé par plusieurs plateformes logicielles courantes, notamment certaines versions de PHP pour Windows. PHP a réagi en publiant des paquets Windows mis à jour le 26 octobre. Cependant, toutes les versions de PHP ne contenaient pas nécessairement le code vulnérable au départ.

Le service « Endless Lifecycle Support » (ELS) de TuxCare pour PHP propose des versions pour Windows, allant de la version 5.2 à la version 8.2, qui ne sont pas vulnérables à la faille CVE-2026-111497. Ces versions n'ont jamais pris en charge Brotli ; il n'y a donc aucun correctif à appliquer pour cette faille en particulier.

Cette conclusion ne reposait ni sur les numéros de version ni sur des hypothèses concernant les dépendances. Deux ingénieurs de TuxCare ont examiné les paquets de version réels et ont effectué quatre tests différents pour vérifier que Brotli ne pouvait être ni chargé ni utilisé.

Voici ce qu'ils ont découvert, ainsi que la marche à suivre pour vérifier la prise en charge de Brotli dans votre propre environnement PHP.

Quelles sont les conséquences réelles de la vulnérabilité CVE-2026-111497 ?

Publié le 22 octobre 2026, 111497 il s'agit d'un débordement de tampon (une écriture hors limites, pour être précis) dans le décodeur Brotli de Google, c/dec/decode.c, et les versions concernées sont Brotli 1.0.3 à 1.0.9, 1.1.0 et 1.2.0. Si un attaquant parvient à faire en sorte qu'un décodeur vulnérable traite un flux Brotli spécialement conçu, cela peut entraîner une corruption de mémoire, une divulgation de mémoire, un plantage ou, potentiellement, l'exécution de code.

Google lui a attribué une note de 9,2 selon le barème CVSS 4.0, et des exploits de démonstration ont déjà été rendus publics. Le 27 octobre, la CISA l'a ajoutée à son catalogue des vulnérabilités connues exploitées, et les tentatives d'exploitation signalées à ce jour ont ciblé Node.js. Les correctifs sont disponibles dans les versions 1.0.10, 1.1.1 et 1.2.1 de Brotli.

Brotli est omniprésent. Les navigateurs, les serveurs web, Node.js, .NET et de nombreux clients HTTP l'utilisent, ce qui explique pourquoi cette vulnérabilité CVE a été mentionnée dans tant d'avis de sécurité émis par les éditeurs, y compris ceux concernant PHP. Mais le fait qu'une ligne y soit mentionnée ne signifie pas pour autant que chaque binaire PHP intègre le décodeur.

Pourquoi certaines versions de PHP pour Windows sont-elles concernées ?

En PHP, pour utiliser Brotli, il faut passer par l'extension cURL, ext/curl. Si libcurl est compilée avec Brotli et qu'un script active la décompression automatique, libcurl signale br dans le Accept-Encoding en-tête et décode tout ce qui lui est renvoyé. La décompression automatique est désactivée par défaut dans cURL, mais les applications et les bibliothèques clientes HTTP peuvent l'activer. Il suffit alors à un serveur malveillant de répondre avec un flux spécialement conçu.

Le changement majeur sous Windows est survenu en PHP 8.2.31, lorsque la compilation en amont a commencé à lier curl à Brotli (commit php-src 0c6fc66848, ext/curl/config.w32). À partir de cette version, les fichiers ZIP officiels de php.net pour Windows sont fournis brotlidec.dll et brotlicommon.dll. Les versions officielles antérieures, notamment les versions 8.1.33/8.1.34 et 8.2.29/8.2.30, ne le font pas. C’est pourquoi l’avis du projet PHP ne concerne que les branches 8.2 à 8.5. Le 26 octobre, php.net a publié de nouveaux paquets pour Windows (8.2.35-1, 8.3.36-1, 8.4.27-1 et 8.5.12-1) intégrant la version corrigée de Brotli 1.2.1.

Les versions ELS de TuxCare se situent plutôt au début de cette évolution. Notre branche 8.2 repose sur la version 8.2.29 et notre branche 8.1 sur la version 8.1.33, tandis que les branches plus anciennes remontent à plusieurs années auparavant. Cependant, une simple comparaison de base ne suffisait pas à clore le dossier.

Bénéficiez d'une assistance illimitée tout au long du cycle de vie de PHP → 

Quelles versions d'ELS pour PHP sous Windows sont concernées ?

Aucune. Aucune version d'ELS pour PHP sous Windows ne contient Brotli dans ses binaires ni ne signale la prise en charge de Brotli via libcurl.

Il s'agit d'une constatation concernant le moteur PHP que nous fournissons, et non d'une généralisation concernant l'ensemble des éléments installés sur l'hôte.

Comment nous avons vérifié les versions finales

La fiabilité d'un verdict « non vulnérable » dépend entièrement des preuves qui l'étayent ; c'est pourquoi deux de nos ingénieurs ont examiné en parallèle les artefacts de la version commercialisée. L'absence d'une DLL ne prouve pas que Brotli ne soit pas compilé quelque part ou qu'il ne puisse pas être chargé d'une autre manière ; ils ont donc effectué quatre tests.

Nous avons recherché du code Brotli dans les fichiers binaires

Chaque décodeur Brotli contient un dictionnaire statique volumineux et spécifique. Nous avons analysé chaque .dll et .exe J'ai parcouru les fichiers ZIP de la version actuelle et je n'ai trouvé aucune correspondance, quelle que soit la version. Aucun fichier DLL Brotli n'est non plus inclus dans aucun des paquets.

Nous avons demandé à libcurl quelles fonctionnalités il prend en charge

À chaque compilation, curl_version() ne signale pas la fonctionnalité Brotli. La bibliothèque libcurl intégrée php_curl a été compilé sans cela. Cela en dit plus long que n'importe quelle recherche de nom de fichier, car cela reflète ce dont le client HTTP est réellement capable.

Nous avons quand même envoyé une réponse au format Brotli

Cadre CURLOPT_ENCODING Une chaîne vide indique à libcurl de proposer tous les encodages qu'elle prend en charge. Elle a proposé deflate, gzip et non br. Nous lui avons ensuite imposé une réponse encodée en Brotli. Des versions 5.6 à 8.2, libcurl a renvoyé l'erreur 61, « libcurl prend en charge les encodages de contenu deflate et gzip ». Avec les versions 5.2 et 5.4, il renvoyait le corps non décodé. Les deux groupes se comportent différemment, mais dans aucun des deux cas les données Brotli n'ont atteint un décodeur.

Nous avons intégré nous-mêmes les DLL

Une question restait en suspens. Et si les DLL Brotli étaient déjà présentes sur la machine ? PHP pourrait-il les détecter lors de l'exécution ?

Le contrôle des importations a donné une réponse négative. Notre php_curl.dll n'a pas d'importance brotlidec.dll, et aucun fichier binaire ne fait référence à brotlidec ou brotlicommon par nom. Nous avons quand même essayé – nous fier uniquement à une table d'importation nous semblait un peu trop simple. Nous avons copié brotlidec.dll et brotlicommon.dll à partir du paquet officiel php.net 8.2.35-1 dans le dossier PHP, le ext dossier et System32, puis nous avons relancé les tests sur nos versions 8.1 et 8.2. Rien n'a changé. Brotli n'était toujours pas proposé, et une réponse Brotli forcée échouait toujours avec l'erreur 61.

Comment vérifier la prise en charge de Brotli sur votre propre hébergeur PHP

Si vous utilisez le service « Endless Lifecycle Support for PHP » de TuxCare sous Windows, vous pouvez vérifier vous-même le fonctionnement de libcurl. Exécutez la commande suivante avec l'exécutable PHP que vous testez :

<?php
$v = curl_version();
echo 'libcurl ', $v['version'], PHP_EOL;

// CURL_VERSION_BROTLI exists on PHP 7.3+; its value is 1 << 23
$brotli = defined('CURL_VERSION_BROTLI') ? CURL_VERSION_BROTLI : (1 << 23);
echo 'Brotli: ', ($v['features'] & $brotli) ? 'YES' : 'no', PHP_EOL;

Dans chaque version d'ELS abordée ici, la dernière ligne indique : Brotli: no. Cela ne vérifie toutefois que les fonctionnalités compilées de libcurl, et non le reste des logiciels installés sur la machine.

Jusqu'où va le verdict de « non vulnérable » ?

Ce verdict concerne uniquement l'ELS pour PHP de TuxCare sur Windows, des versions 5.2 à 8.2, et rien d'autre. Un module de serveur web, Node.js, .NET, un navigateur ou une version autonome de curl sur le même serveur peut intégrer son propre Brotli et nécessite donc une vérification distincte. Node.js est le premier élément à vérifier, car son Brotli intégré est concerné dans les versions 22.x, 24.x et 26.x ; les correctifs sont disponibles dans les versions 22.23.4, 24.22.1 et 26.12.1. L’extension PHP Brotli distincte, si vous l’avez installée, comporte également son propre décodeur (corrigé dans la version 0.21.1). Pour tout autre cas, mettez à jour les versions Brotli concernées vers la version 1.0.10, 1.1.1 ou 1.2.1.

Vous utilisez un paquet Windows « en amont » de php.net à partir de la version 8.2.31 ? Dans ce cas, votre version intègre bien Brotli, et c’est l’avis du projet PHP qu’il convient de suivre. La solution consiste à effectuer une recompilation « -1 » pour votre branche. Comme le code source de PHP n’a pas changé, la commande `php -v` affiche le même numéro de version avant et après ; seule la date de compilation change (la version 8.2.35 indique « built: 20 oct. 2026 », tandis que la version 8.2.35-1 indique « built: 26 oct. 2026 »). La vérification directe s’effectue via `curl_version()['brotli_version']` : le paquet 8.2.35 d’origine renvoie `brotli/1.2.0`, tandis que la recompilation 8.2.35-1 renvoie `brotli/1.2.1`.

Pourquoi il est important de prouver une négation

La majeure partie du travail de sécurité sur un environnement d'exécution en fin de vie consiste à identifier les vulnérabilités concernées et à les corriger. L'autre partie consiste à vérifier celles qui ne le sont pas, afin que votre équipe ne gaspille pas une fenêtre de maintenance sur un problème inexistant ou ne laisse pas un scanner détecter indéfiniment une faille.

En ce qui concerne le CVE-2026-111497, les quatre tests aboutissent tous au même résultat ; les équipes travaillant sur ces versions peuvent donc consigner la conclusion selon laquelle la vulnérabilité n'est pas présente et clore le dossier. Vous pouvez consulter ce CVE ainsi que d'autres dans l'ensemble des produits TuxCare via le TuxCare CVE Tracker.

Vous avez des questions sur ELS pour PHP sous Windows ? Contactez l'un de nos experts en correctifs PHP.

Bénéficiez d'une assistance illimitée tout au long du cycle de vie de PHP → 

Foire aux questions

Est-ce que php -v Comment savoir si mon PHP sous Windows dispose du correctif Brotli ?

Pas directement. php.neta mis à jour Brotli dans ses versions Windows du 26 octobre sans modifier le code source de PHP ; ainsi, un paquet 8.2.35-1 corrigé indique toujours la version 8.2.35. Seule la date de compilation change, passant du 20 octobre au 26 octobre 2026. Pour obtenir une réponse directe, exécutez la commande php -r « echo curl_version()[‘brotli_version’]; ». La mention « brotli/1.2.1 » indique que le décodeur a été corrigé ; « brotli/1.2.0 » signifie que vous devez encore effectuer la recompilation.

La vulnérabilité CVE-2026-111497 fait-elle l'objet d'exploits ?

Oui. La CISA l’a ajoutée au catalogue des vulnérabilités connues exploitées le 27 octobre, et les éditeurs de solutions de sécurité ont depuis signalé des tentatives d’exploitation visant Node.js. Cela ne signifie pas pour autant que PHP pour Windows soit exploité, et les versions ELS pour PHP sur Windows proposées par TuxCare ne contiennent absolument pas le décodeur vulnérable.

Les clients utilisant TuxCare ELS pour PHP sous Windows doivent-ils effectuer des démarches particulières ?

Ce n'est pas le cas pour cette vulnérabilité CVE. Les versions concernées ici, de la 5.2 à la 8.2, ne nécessitent aucune mise à jour ; vous pouvez donc consigner le résultat « non vulnérable » et clore le ticket du scanner.