Un solo fallo en Brotli, muchos productos afectados: CVE-2026-111497 alcanza a Node.js, Bun, Python y Envoy
Un fallo de seguridad de memoria en la biblioteca de referencia para descomprimir Brotli se ha convertido en un ejercicio de parcheo que atraviesa varios ecosistemas. Identificado como CVE-2026-111497, permite que datos comprimidos con Brotli especialmente manipulados escriban más allá del final de un búfer. Como el mismo decodificador está integrado en runtimes, proxies y bibliotecas de Python, la corrección debe llegar producto por producto, y algunos todavía se están poniendo al día.
Qué ha pasado
El 21 de octubre de 2026 se publicaron versiones corregidas de Node.js y una biblioteca Brotli actualizada, y en los días siguientes han ido llegando parches para el resto del software afectado. El cambio que cierra el agujero entró en realidad en el código fuente de Brotli en febrero, pero en ese momento nadie lo identificó como una corrección de seguridad y ninguna versión de Brotli lo incluyó hasta octubre, de modo que los proyectos dependientes siguieron distribuyendo el decodificador vulnerable durante meses.
Una carga maliciosa puede corromper la memoria y provocar un cierre inesperado, una fuga de memoria o, en el peor de los casos, la ejecución de código controlado por el atacante. La ejecución remota de código se ha demostrado en una única compilación sin parchear —Node.js 24.22.0 para Linux en ARM64—, tanto mediante una respuesta obtenida con fetch como mediante un cuerpo de petición subido. Requirió varios intentos, el exploit no se ha publicado y no se ha demostrado ejecución de código en los demás productos afectados. No se ha informado de explotación activa, ni existe una prueba de concepto pública fiable.
La gravedad depende de quién la puntúe: el CVE tiene una puntuación crítica de 9,2 en CVSS 4.0, mientras que algunos fabricantes lo clasifican como alto o importante (alrededor de 8,1).
A quién afecta
| Software | Vulnerable | Corregido | Expuesto cuando |
|---|---|---|---|
| Node.js | versiones anteriores a la actualización de seguridad del 21 de octubre | versiones de seguridad del 21 de octubre | fetch() lee una respuesta br, o un body parser descomprime una subida Brotli |
| Bun | 1.4.3 y anteriores | 1.4.4 | fetch() lee una respuesta br, o el código usa node:zlib |
| Envoy | hasta 1.39.2, 1.38.5, 1.37.7, 1.36.11 | 1.40.0, 1.39.3, 1.38.6, 1.37.8, 1.36.12 | el descompresor Brotli está configurado |
| Istio | 1.31.0–1.31.1, 1.30.0–1.30.5, 1.29.0–1.29.8 | 1.31.2, 1.30.6, 1.29.9 | la descompresión Brotli está activada |
Python Brotli | 1.2.0 y anteriores | 1.2.1 | instalado, y un cliente HTTP decodifica br |
Python brotlicffi | 1.2.0.x y anteriores | 1.2.1.0 | instalado, y un cliente HTTP decodifica br |
| cdxgen | binarios/imágenes independientes 13.4.0, 12.8.8 y anteriores | 13.5.0, 12.8.9 | analiza entradas no confiables |
Por qué importa
La pregunta clave es sencilla: ¿tu software decodifica datos Brotli que controla otra persona?
- Node.js y Bun están expuestos cuando el
fetch()integrado recibe una respuesta enviada conContent-Encoding: br, o cuando un middleware de cuerpo de petición —por ejemplo, Express 5 con body-parser 2— descomprime una subida Brotli. Un servidor HTTP de Node.js básico no decodifica por sí mismo los cuerpos de las peticiones. - Envoy e Istio solo son alcanzables cuando la descompresión Brotli está activada, por ejemplo mediante un filtro de Envoy. Si está desactivada, el fallo no puede activarse.
- Python es el caso más traicionero. Basta con tener instalado
Brotliobrotlicffi: clientes HTTP populares como requests, urllib3, httpx y aiohttp los usan automáticamente y decodifican por su cuenta las respuestas Brotli. Una aplicación puede quedar expuesta sin importar nunca Brotli en su propio código.
El fallo funciona además en ambos sentidos. Un servidor sin parchear que acepte entradas comprimidas podría ser tomado por un cliente malicioso, y un cliente sin parchear que acepte respuestas comprimidas podría ser tomado por un servidor malicioso. Un firewall de aplicaciones web puede filtrar el tráfico entrante, pero no protege las respuestas que tu propio código obtiene de otros servidores: en ese camino, solo la actualización cierra la brecha.
Dos puntos ciegos dificultan el seguimiento. El registro del CVE apunta al repositorio original de Brotli y no a los paquetes de PyPI, por lo que los escáneres de dependencias que se basan en los avisos de GitHub quizá aún no detecten las bibliotecas de Python; las entradas específicas (PYSEC-2026-4322 y PYSEC-2026-4323) no se añadieron hasta el 23 de octubre. Además, los paquetes de sistema avanzan a ritmos distintos: Debian 13 (trixie) publicó un paquete brotli corregido (1.1.0-2+deb13u1) el 23 de octubre, mientras que Amazon Linux 2023 seguía mostrando sus paquetes brotli y Node.js 24 como pendientes de corrección a 22 de octubre.
Qué hacer
- Actualiza a una versión corregida de la tabla anterior y después reinicia los servicios y reconstruye las imágenes de contenedor: un proceso en ejecución mantiene el decodificador antiguo en memoria hasta que se reinicia.
- Si todavía no puedes actualizar, deja de decodificar Brotli no confiable:
- rechaza las peticiones entrantes con
Content-Encoding: brantes de que cualquier proxy o parser decodifique el cuerpo; - desactiva la decodificación automática de Brotli en los clientes HTTP y rechaza las respuestas Brotli antes de decodificarlas;
- en Python, desinstala
Brotliybrotlicffipara que los clientes vuelvan a gzip y deflate.
- rechaza las peticiones entrantes con
- No confíes solo en
Accept-Encoding. Quitarbrde esa cabecera no es por sí solo una defensa: un servidor hostil puede enviar Brotli pida lo que pida el cliente. Para Node.js no hay ninguna mitigación publicada: actualizar el runtime es la solución. - Comprueba manualmente, no solo con tu escáner. Ejecuta
pip show brotli brotlicffien todos tus entornos e imágenes de Python y sigue los paquetes brotli y Node.js de tu distribución hasta que estén corregidos.
Este tipo de fallos se esconde en dependencias opcionales y transitivas que nadie eligió a propósito. Nuestra revisión de código asistida por IA inventaría lo que tus aplicaciones cargan realmente —incluidas las bibliotecas que los clientes HTTP utilizan en silencio— y lo contrasta con los avisos de seguridad vigentes, para que un decodificador vulnerable no pase desapercibido solo porque tu código nunca lo importa directamente.
