Brotli CVE-2026-111497: la falla está en el decodificador, y tener la librería no es estar expuesto

Brotli es la librería de compresión detrás del Content-Encoding: br que usa casi toda la web. Ayer entró al catálogo de fallas explotadas de CISA un desbordamiento en su decodificador, y el alcance es incómodo justamente porque Brotli no es un producto que uno instale: viene adentro de otras cosas.

Las versiones, que es lo primero: la falla afecta a Brotli 1.0.3 hasta 1.2.0, y Google dice que hay que pasar a 1.0.10, 1.1.1 o 1.2.1, según la rama. Por arrastre, Node.js publicó 22.23.4, 24.22.1 y 26.12.1, y .NET publicó 8.0.33, 9.0.22 y 10.0.14.

Y el matiz que decide si esto te toca, que viene del aviso de Microsoft y conviene leer antes de entrar en pánico o de ignorarlo: "una aplicación no queda expuesta solamente porque un paquete afectado de .NET esté instalado". Hace falta algo más: que tu código descomprima datos Brotli que no produjo él.

Qué versión corrige Brotli en cada ecosistema

Hay un cuarto frente que conviene nombrar aunque no lo pueda detallar: las distribuciones de Linux empaquetan Brotli por su cuenta, y hay un aviso de Debian LTS entre las referencias de la ficha. Si tu servidor instala Brotli desde el repositorio de la distribución, el número que importa es el del paquete de esa distribución, no el de Google.

Cuál es la falla, según el aviso de Node.js

La descripción más clara del mecanismo es la de Node.js, y vale citarla porque explica por qué un formato de compresión termina en ejecución de código: "Un cambio de bloque inválido se reportó como una necesidad temporal de más entrada en lugar de un error permanente de formato, así que el decodificador en flujo siguió agregando bytes de entrada a un búfer interno de ocho bytes."

Dicho en castellano llano: el decodificador recibe algo mal formado, lo interpreta como "me falta información, seguí mandando" en lugar de "esto está roto, corto", y sigue escribiendo en un espacio de 8 bytes que no crece.

Google lo ubica en el archivo del decodificador, c/dec/decode.c, y describe el resultado: un atacante remoto sin autenticarse puede corromper memoria adyacente del estado del decodificador, revelar contenidos de memoria, provocar una denegación de servicio o potencialmente ejecutar código arbitrario, usando un flujo comprimido en Brotli construido a propósito.

Las dos debilidades que le asigna Google son CWE-252, valor de retorno sin verificar, y CWE-787, escritura fuera de rango. La primera explica la segunda: nadie miró lo que devolvió una función, y por eso se escribió donde no correspondía.

Tener Brotli instalado no es estar expuesto

Esta es la parte que distingue una nota útil de una alarma. El aviso de Microsoft es inusualmente explícito y conviene tomarlo en serio: ni ASP.NET Core ni HttpClient descomprimen Brotli de forma predeterminada. Para quedar expuesto hace falta una de tres cosas, y las tres son decisiones que alguien tomó en el código o en la configuración.

El aviso de Node.js apunta a lo mismo desde el otro lado: la condición es que "un atacante pueda suministrar datos Brotli que una aplicación descomprima con node:zlib".

Así que la pregunta correcta no es "¿tengo Brotli?" —lo tenés, casi seguro— sino "¿mi código descomprime Brotli que vino de afuera?". Los dos casos típicos donde la respuesta es sí: una aplicación que acepta cuerpos de petición comprimidos, y una aplicación que va a buscar contenido a una URL que no controla y acepta respuestas en br.

Un detalle de Microsoft que es fácil pasar por alto y que rompe el plan de "actualizo el runtime y listo": en aplicaciones NativeAOT, "actualizar el runtime compartido de la máquina por sí solo no reemplaza un decodificador que ya quedó enlazado dentro de un ejecutable NativeAOT". Esas hay que volver a publicar y desplegar. Lo mismo para las autocontenidas.

Dónde no coinciden CISA, Google y Microsoft

Acá se repite, con más filo, algo que ya apareció ayer con las fallas de PHP: CISA cuenta la falla como explotada y ningún aviso de fabricante describe explotación observada. Pero esta vez hay un dato más duro: el vector de Microsoft incluye la métrica temporal de madurez de explotación con el valor E:U, "Unproven", es decir no probada.

No voy a resolver la contradicción porque no tengo con qué. Lo que sí se puede decir es de dónde sale cada afirmación: Microsoft publicó su vector el 25 de octubre y CISA sumó la falla al catálogo el 27, dos días después. Puede ser que CISA tenga información que Microsoft no tenía, puede ser que el vector no se haya actualizado. Las dos cosas son posibles y ninguna está escrita.

Y para la serie: esta ficha no tiene puntaje propio de NVD, porque figura en estado "Undergoing Analysis". Es exactamente el patrón que medí el lunes sobre quién calcula los puntajes: el número que circula es el del fabricante.

¿A quién afecta CVE-2026-111497?

Si tenés una aplicación en Node.js, es el caso más probable de todos, porque el decodificador viene incluido en Node y el consumo de APIs externas es rutina. La pregunta concreta: ¿tu código llama a node:zlib con datos que vinieron de un tercero, o va a buscar URLs que no controlás?

Si tenés una aplicación en .NET, mirá las tres condiciones de arriba antes de mover nada. Si ninguna aplica, actualizá por higiene y no por urgencia. Y si usás NativeAOT o publicás autocontenido, el runtime de la máquina no te alcanza.

Si administrás servidores Linux, el número que importa es el del paquete de tu distribución, y conviene mirarlo aunque la aplicación no descomprima nada: hay otros consumidores de la librería en el sistema.

Si tenés una PyME con sitio y nada más, esto probablemente lo resuelve tu proveedor sin que te enteres, igual que las fallas de PHP de ayer. Lo que sí conviene es preguntarlo por escrito, y el formato está en cómo responder un cuestionario de seguridad de un cliente. Qué queda del lado del hosting está en qué cubre el hosting en materia de seguridad.

Si desarrollás sobre librerías ajenas, el patrón es el de siempre y ya apareció con las 32 fallas de IBM Langflow: el inventario de lo que tenés abajo pesa más que el de lo que escribiste.

¿Quién puede ignorar el plazo del 10 de noviembre?

El plazo del 10 de noviembre —14 días desde el alta— obliga a las agencias federales civiles de Estados Unidos, no a una PyME de la región. Y vale notar la diferencia de criterio: a las fallas de PHP de esta semana CISA les dio 3 días, y a esta le dio 14. Con las descripciones públicas no se puede saber por qué, y no voy a inventarlo.

Quien no descomprima Brotli de datos ajenos puede tratar esto como mantenimiento normal, según los propios avisos. La actualización igual conviene, porque la condición puede cambiar con una línea de configuración que alguien agregue el mes que viene.

Lo que no corresponde es la lectura de que "todo servidor web con br activado es explotable". Servir contenido comprimido no es lo mismo que descomprimir contenido ajeno: el que corre riesgo es el que decodifica, no el que codifica.

¿Cómo sé si mi aplicación descomprime Brotli de afuera?

Sin herramientas, tres revisiones concretas:

1. En Node.js, buscá en el código llamadas a brotliDecompress, brotliDecompressSync o createBrotliDecompress de node:zlib, y fijate de dónde viene el dato que les pasás. Si viene de una petición, de una cola o de una URL externa, entrás en la condición del aviso.
2. En .NET, buscá BrotliStream y BrotliDecoder en el código; revisá si en el arranque hay DecompressionProviders con "br"; y revisá si algún HttpClientHandler o SocketsHttpHandler tiene AutomaticDecompression con Brotli o con All.
3. En cualquier stack, preguntate si tu aplicación acepta cuerpos de petición comprimidos. Es la vía por la que un atacante te manda el flujo malicioso sin necesidad de que vos vayas a buscarlo.

Para detectar, no hay indicadores publicados en estos avisos, así que lo que queda es conducta: un proceso de aplicación que se cae repetidamente al procesar entradas, o que empieza a hacer cosas que no hacía, es la señal. Mirar conducta en lugar de firmas es la diferencia que explico en cuándo se justifica un EDR en una PyME y en la categoría de antivirus y EDR.

¿Qué hago si no puedo actualizar Node.js o .NET ya mismo?

Microsoft publica mitigaciones concretas, con una advertencia que conviene respetar:

1. En ASP.NET Core, quitar el proveedor br de la configuración existente: options.DecompressionProviders.Remove("br");
2. En HttpClient, cambiar las banderas existentes a DecompressionMethods.GZip | DecompressionMethods.Deflate, para que excluyan Brotli.
3. Si usás las interfaces directas, dejar de pasarles datos Brotli que no sean de confianza.
4. La advertencia: Microsoft dice no agregar estas configuraciones si tu aplicación no usa descompresión, y que los cambios se prueben antes de desplegar. Instalar la actualización sigue siendo la corrección recomendada.
5. Después de actualizar, reiniciar las aplicaciones. Y volver a publicar y desplegar las autocontenidas y las NativeAOT, porque el decodificador va enlazado adentro.

Para Node.js el aviso no publica mitigación de configuración: la salida es la versión. El encuadre general de qué pedirle a la infraestructura de una PyME está en la guía de ciberseguridad para PyMEs de LATAM.

Una aclaración sobre las fuentes y sobre lo que no verifiqué. Lo que sí pude leer: la ficha de la API de NVD de CVE-2026-111497, que trae la descripción de Google con el rango afectado, las tres versiones correctoras y el archivo del decodificador; la página de la versión 1.2.1 de Brotli, cuyas notas dicen solo "CVE-2026-111497: out-of-bounds write permits remote code execution"; el aviso de seguridad de Node.js del 21 de octubre, de donde salen las líneas afectadas, las versiones publicadas, la descripción del mecanismo y la condición de exposición; el aviso de Microsoft para .NET del 25 de octubre en su versión 1.0, de donde salen las versiones, las tres condiciones de exposición, las mitigaciones, la advertencia sobre NativeAOT y el vector con E:U; y el feed JSON del catálogo KEV. Lo que no pude verificar: qué número de paquete corrige en cada distribución de Linux, así que no doy ninguno; y si la reimplementación de Brotli en Go comparte el defecto, porque es otro código y no leí su aviso, así que no afirmo nada sobre ella. Lo que no incluyo: ninguno de los análisis técnicos públicos ni las páginas de demostración que referencia la ficha. El mecanismo y la condición de exposición están arriba; el paso a paso no, y el parche tiene 7 días.

La otra alta del catálogo de ayer fue CVE-2026-48356, una subida de archivos sin restricción en Adobe Commerce y Magento que puede terminar en ejecución de código, con el mismo plazo del 10 de noviembre y aviso propio de Adobe. No la cubro acá para no mezclar dos historias distintas; el antecedente de ese producto está en la falla de Magento y Adobe Commerce de StyleSmuggler.

Preguntas frecuentes sobre CVE-2026-111497 en Brotli

¿Tengo Brotli y no lo sabía?

Casi con seguridad sí, y es el punto incómodo de esta falla. Brotli es la librería detrás del Content-Encoding: br, y viene empaquetada dentro de Node.js, de .NET, de los navegadores, de servidores web y de las distribuciones de Linux. No es algo que se instale por separado, así que no aparece en una lista de programas instalados. Lo que importa no es si lo tenés, sino si tu código descomprime datos Brotli que no produjo él.

¿Mi servidor web con compresión Brotli activada es explotable?

No por eso solo. Servir contenido comprimido es codificar, y la falla está en decodificar. El riesgo aparece cuando algo descomprime un flujo Brotli que vino de afuera: una aplicación que acepta cuerpos de petición comprimidos, o una que va a buscar contenido a una URL que no controla y acepta respuestas en br. Igual conviene actualizar el paquete, porque suele haber más de un consumidor de la librería en el sistema.

Uso .NET. ¿Qué miro antes de salir corriendo?

Las tres condiciones que publica Microsoft, porque dice textualmente que una aplicación no queda expuesta solo por tener el paquete instalado, y que ni ASP.NET Core ni HttpClient descomprimen Brotli de forma predeterminada. Hace falta que tengas la descompresión automática de peticiones con el proveedor br, o un AutomaticDecompression que incluya Brotli o All, o uso directo de BrotliStream o BrotliDecoder. Si nada de eso aplica, actualizá con calma. Y si publicás NativeAOT o autocontenido, actualizar el runtime de la máquina no alcanza: hay que volver a publicar.

¿Qué versión de Node.js tengo que tener?

Las versiones de seguridad publicadas el 21 de octubre son 22.23.4, 24.22.1 y 26.12.1, una por cada línea afectada: 22.x, 24.x y 26.x. El aviso no publica una mitigación de configuración para esta falla, así que la salida es actualizar. Vale saber que esa misma tanda corrigió nueve CVE más, entre ellas tres de severidad alta que afectan la validación de nombres en certificados TLS, así que la actualización rinde más que esta falla sola.

¿Está siendo explotada de verdad?

Las fuentes no coinciden, y lo honesto es decirlo así. CISA sumó la falla a su catálogo de vulnerabilidades explotadas el 27 de octubre, y estar ahí significa explotación conocida por definición. Pero el vector que publicó Microsoft el 25 de octubre incluye la madurez de explotación como "Unproven", no probada, y ninguno de los avisos de los fabricantes describe explotación observada en el mundo real. Puede que CISA tenga información que Microsoft no tenía dos días antes; no está escrito en ninguna parte. Para decidir qué hacer no cambia nada: las versiones corregidas existen desde el 21 de octubre.