¿Sigues utilizando una versión de PHP obsoleta? Manténla segura.
La vulnerabilidad CVE-2026-111497 nunca afectó a las compilaciones del servicio «Endless Lifecycle Support» (ELS) de TuxCare para PHP en Windows. Y cuando sí se producen vulnerabilidades, ELS ofrece parches de seguridad retrocompatibles para las versiones de PHP 5.2 a 8.2 en Windows, sin obligar a realizar una actualización. Disfruta de protección continua para las versiones de las que ya dependen tus aplicaciones.
Principales conclusiones
- El servicio de soporte técnico de ciclo de vida ilimitado de TuxCare para PHP en Windows, desde la versión 5.2 hasta la 8.2, no se ve afectado por el CVE-2026-111497.
- No es necesario realizar ninguna actualización, ya que las versiones de TuxCare no incluyen código Brotli y su libcurl nunca negocia Brotli.
- Las analizaciones binarias, las comprobaciones de las funciones de libcurl, las pruebas HTTP en tiempo real y una prueba de carga lateral de DLL confirmaron el resultado.
- Las compilaciones de php.net para Windows, a partir de la versión PHP 8.2.31, incluyen Brotli y requieren las compilaciones actualizadas de php.net del 26 de octubre.
CVE-2026-111497 puso de manifiesto una grave vulnerabilidad en el decodificador Brotli utilizado por varias plataformas de software populares, incluidas algunas versiones de PHP para Windows. PHP respondió con paquetes actualizados para Windows el 26 de octubre. Sin embargo, no todas las versiones de PHP contenían el código vulnerable desde un principio.
El servicio «Endless Lifecycle Support» (ELS) de TuxCare para PHP ofrece versiones para Windows que abarcan desde la 5.2 hasta la 8.2 y que no son vulnerables a CVE-2026-111497. Estas versiones nunca incluyeron compatibilidad con Brotli, por lo que no hay que aplicar ningún parche para esta vulnerabilidad en concreto.
Esa conclusión no se basó en números de versión ni en suposiciones sobre dependencias. Dos ingenieros de TuxCare examinaron los paquetes de lanzamiento reales y realizaron cuatro pruebas diferentes para verificar que Brotli no se pudiera cargar ni utilizar.
Esto es lo que descubrieron y cómo comprobar si tu propio entorno PHP es compatible con Brotli.
A qué afecta realmente el CVE-2026-111497
Publicado el 22 de octubre de 2026, 111497 se trata de un desbordamiento de búfer (una escritura fuera de límites, para ser exactos) en el decodificador Brotli de Google, c/dec/decode.c, y las versiones afectadas son Brotli 1.0.3 a 1.0.9, 1.1.0 y 1.2.0. Si un atacante consigue que un decodificador vulnerable procese un flujo Brotli manipulado, el resultado puede ser una corrupción de memoria, una revelación de memoria, un fallo del sistema o, potencialmente, la ejecución de código.
Google le ha asignado una puntuación de 9,2 según el CVSS 4.0, y ya se han publicado exploits públicos de prueba de concepto. El 27 de octubre, la CISA la añadió a su catálogo de vulnerabilidades explotadas conocidas, y los intentos de explotación notificados hasta la fecha se han dirigido contra Node.js. Las correcciones se incluyen en las versiones 1.0.10, 1.1.1 y 1.2.1 de Brotli.
Brotli está en todas partes. Los navegadores, los servidores web, Node.js, .NET y muchos clientes HTTP lo utilizan, por lo que la vulnerabilidad CVE apareció en tantos avisos de proveedores, incluidos los de PHP. Pero el hecho de que aparezca una línea al respecto en un aviso de PHP no significa que todos los binarios de PHP incluyan el decodificador.
Por qué algunas compilaciones de PHP para Windows se ven afectadas
En PHP, el camino hacia Brotli pasa por la extensión cURL, ext/curl. Si libcurl se compila con Brotli y un script activa la descompresión automática, libcurl indica br en el Accept-Encoding encabezado y descodifica cualquier respuesta que reciba. La descompresión automática está desactivada por defecto en cURL, pero las aplicaciones y las bibliotecas de clientes HTTP pueden activarla. Una vez hecho esto, un servidor malicioso solo tiene que responder con un flujo manipulado.
El cambio más importante en Windows se produjo en PHP 8.2.31, cuando la compilación de la rama principal comenzó a vincular curl con Brotli (commit de php-src 0c6fc66848, ext/curl/config.w32). A partir de esa versión, los archivos ZIP oficiales de php.net para Windows se distribuyen brotlidec.dll y brotlicommon.dll. Los paquetes oficiales anteriores, incluidos los 8.1.33/8.1.34 y 8.2.29/8.2.30, no lo hacen. Por eso, el aviso del proyecto PHP solo abarca las ramas de la 8.2 a la 8.5. El 26 de octubre, php.net publicó nuevos paquetes para Windows (8.2.35-1, 8.3.36-1, 8.4.27-1 y 8.5.12-1) que incluyen la versión corregida de Brotli 1.2.1.
Las compilaciones de ELS de TuxCare se sitúan en la fase inicial de ese cambio. Nuestra línea 8.2 se basa en la versión 8.2.29 y nuestra línea 8.1, en la 8.1.33, mientras que las líneas más antiguas son de hace años. Aun así, una simple comparación de referencia no bastaba para dar el asunto por zanjado.
Consigue asistencia técnica ilimitada durante todo el ciclo de vida de PHP →
¿Qué versiones de ELS para PHP en Windows se ven afectadas?
Ninguna de ellas. Ninguna de las compilaciones de ELS para PHP en Windows incluye Brotli en sus binarios ni indica que sea compatible con Brotli a través de libcurl.
| ELS para PHP en Windows | Brotli en archivos binarios | Compatibilidad con Brotli en libcurl | Estado de CVE-2026-111497 |
| 5.2 | No | No | No es vulnerable |
| 5.4 | No | No | No es vulnerable |
| 5.6 | No | No | No es vulnerable |
| 7.2 | No | No | No es vulnerable |
| 7.3 | No | No | No es vulnerable |
| 7.4 | No | No | No es vulnerable |
| 8.0 | No | No | No es vulnerable |
| 8.1 (basado en 8.1.33) | No | No | No es vulnerable |
| 8.2 (basado en 8.2.29) | No | No | No es vulnerable |
Se trata de una observación sobre el entorno de ejecución de PHP que incluimos, no de una afirmación general sobre todo lo que está instalado en el servidor.
Cómo comprobamos las versiones finales de lanzamiento
Un veredicto de «no vulnerable» solo es válido en la medida en que lo respalden las pruebas, por lo que dos de nuestros ingenieros revisaron en paralelo los artefactos de la versión lanzada. La ausencia de un archivo DLL no demuestra que Brotli no esté compilado en algún lugar o que no se pueda cargar de otra forma, por lo que realizaron cuatro pruebas.
Hemos buscado código de Brotli en los archivos binarios
Cada decodificador Brotli contiene un diccionario estático extenso y característico. Hemos analizado cada .dll y .exe He buscado en los archivos ZIP de la versión actual y no he encontrado ninguna coincidencia, en ninguna compilación. Tampoco se incluye ninguna DLL de Brotli en ninguno de los paquetes.
Le preguntamos a libcurl qué es lo que admite
En cada compilación, curl_version() no informa de la función Brotli. La libcurl que hay dentro de php_curl se compiló sin él. Eso dice más que cualquier búsqueda por nombre de archivo, porque refleja lo que el cliente HTTP puede hacer realmente.
De todos modos, enviamos una respuesta en formato Brotli
Escenario CURLOPT_ENCODING Una cadena vacía indica a libcurl que ofrezca todas las codificaciones que admite. Ofreció deflate, gzip y no br. A continuación, le impusimos una respuesta codificada con Brotli. En las versiones 5.6 a 8.2, libcurl la rechazó con el error 61, «libcurl admite las codificaciones de contenido deflate y gzip». En las versiones 5.2 y 5.4, devolvía el cuerpo sin descodificar. Los dos grupos se comportan de forma diferente, pero en ninguno de los dos casos los datos Brotli llegaron a un descodificador.
Nosotros mismos hemos colocado los archivos DLL
Quedaba una pregunta por resolver. ¿Y si las DLL de Brotli ya estuvieran instaladas en el equipo? ¿Podría PHP detectarlas en tiempo de ejecución?
La comprobación de importación dio negativo. Nuestra php_curl.dll no importa brotlidec.dll, y ningún binario hace referencia a brotlidec o brotlicommon por nombre. Lo probamos de todos modos; confiar únicamente en una tabla de importación nos parecía demasiado sencillo. Copiamos brotlidec.dll y brotlicommon.dll del paquete oficial php.net 8.2.35-1 a la carpeta PHP, el ext carpeta y System32, y luego volvimos a ejecutar las pruebas en nuestras versiones 8.1 y 8.2. No cambió nada. Brotli seguía sin ofrecerse, y al forzar una respuesta con Brotli seguía fallando con el error 61.
Cómo comprobar si tu propio servidor PHP es compatible con Brotli
Si utilizas el servicio «Endless Lifecycle Support for PHP» de TuxCare en Windows, puedes comprobar tú mismo el estado de libcurl. Ejecuta este comando con el ejecutable de PHP que estés evaluando:
<?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;
En todas las compilaciones de ELS que se tratan aquí, la última línea dice: Brotli: no. Sin embargo, solo comprueba las características compiladas de libcurl, no el resto del software instalado en el equipo.
Hasta dónde llega el veredicto de «no vulnerable»
Este veredicto se refiere únicamente a ELS de TuxCare para PHP en Windows, desde la versión 5.2 hasta la 8.2, y a nada más. Un módulo de servidor web, Node.js, .NET, un navegador o una aplicación independiente de curl en el mismo servidor pueden incluir su propio Brotli y requieren una comprobación independiente. Node.js es lo primero que hay que comprobar, ya que su Brotli integrado se ve afectado en las versiones 22.x, 24.x y 26.x, con correcciones en las versiones 22.23.4, 24.22.1 y 26.12.1. La extensión independiente de Brotli para PHP, si la tienes instalada, también incluye su propio decodificador (corregido en la versión 0.21.1). Para cualquier otro caso, actualiza las versiones afectadas de Brotli a la 1.0.10, 1.1.1 o 1.2.1.
¿Estás ejecutando un paquete de Windows de php.net «upstream» a partir de la versión 8.2.31? En ese caso, tu compilación incluye Brotli, por lo que debes seguir las recomendaciones del proyecto PHP. La solución es la recompilación con el sufijo -1 para tu rama. Como el código fuente de PHP no ha cambiado, php -v muestra el mismo número de versión antes y después; solo cambia la fecha de compilación (la versión 8.2.35 indica «compilada el 20 de octubre de 2026», mientras que la 8.2.35-1 indica «compilada el 26 de octubre de 2026»). La comprobación directa es curl_version()[‘brotli_version’]: el paquete original 8.2.35 devuelve brotli/1.2.0, mientras que la recompilación 8.2.35-1 devuelve brotli/1.2.1.
Por qué es importante demostrar una negación
La mayor parte del trabajo de seguridad en un entorno de ejecución al final de su ciclo de vida consiste en detectar las vulnerabilidades que afectan al sistema y aplicarles los parches correspondientes. La otra parte consiste en demostrar cuáles no afectan, para que tu equipo no malgaste un periodo de mantenimiento en un problema inexistente ni deje un escáner buscando vulnerabilidades de forma indefinida.
En el caso de CVE-2026-111497, las cuatro pruebas apuntan en la misma dirección, por lo que los equipos que trabajen con estas versiones pueden documentar que no existe vulnerabilidad y dar el asunto por zanjado. Puedes consultar este y otros CVE de los productos de TuxCare en el TuxCare CVE Tracker.
¿Tienes alguna duda sobre ELS para PHP en Windows? Ponte en contacto con uno de nuestros expertos en parches de PHP.
Consigue asistencia técnica ilimitada durante todo el ciclo de vida de PHP →
Preguntas frecuentes
¿Es así? php -v ¿Cómo puedo saber si mi PHP de Windows tiene la corrección de Brotli?
No directamente. php.netactualizó Brotli en sus compilaciones para Windows del 26 de octubre sin modificar el código fuente de PHP, por lo que un paquete 8.2.35-1 parcheado sigue indicando la versión 8.2.35. Solo cambia la fecha de compilación, del 20 al 26 de octubre de 2026. Para obtener una respuesta directa, ejecuta php -r «echo curl_version()[‘brotli_version’];». brotli/1.2.1 significa que el decodificador está corregido; brotli/1.2.0 significa que aún necesitas la nueva compilación.
¿Se está aprovechando la vulnerabilidad CVE-2026-111497?
Sí. La CISA la incluyó en el catálogo de «Vulnerabilidades explotadas conocidas» el 27 de octubre, y desde entonces los proveedores de seguridad han informado de intentos de explotación contra Node.js. Eso no significa que se esté explotando PHP para Windows, y las compilaciones de ELS para PHP en Windows de TuxCare no contienen en absoluto el decodificador vulnerable.
¿Tienen que hacer algo los clientes de TuxCare ELS para PHP en Windows?
No en el caso de este CVE. Las versiones analizadas aquí, desde la 5.2 hasta la 8.2, no necesitan ninguna actualización, por lo que puedes documentar el resultado de que no hay vulnerabilidad y cerrar el ticket del escáner.