Descargar una página, consultar una API o procesar contenido remoto parece una operación rutinaria. Pero a veces la parte peligrosa no es el contenido visible, sino algo que ocurre antes de que la aplicación pueda leerlo: la descompresión de la respuesta.

CVE-2026-111497 es una vulnerabilidad de escritura fuera de límites (out-of-bounds write, CWE-787) en el decodificador de Brotli, un formato de compresión empleado ampliamente en la web. Una secuencia comprimida especialmente malformada puede provocar corrupción de memoria cuando un programa intenta descomprimirla.

El riesgo no está limitado a un servicio concreto ni a los extractores de vídeo. Puede alcanzar navegadores, clientes HTTP, servicios backend, runtimes o bibliotecas que incorporan una versión afectada del decodificador y aceptan datos Brotli controlados por terceros.

Qué es Brotli y por qué aparece en tantas aplicaciones

Brotli es un algoritmo de compresión sin pérdida. En HTTP suele anunciarse con el identificador br.

GET /recurso HTTP/1.1
Host: example.org
Accept-Encoding: gzip, deflate, br

Un servidor puede responder con:

HTTP/1.1 200 OK
Content-Encoding: br
Content-Type: application/json

Antes de interpretar el JSON o el HTML, el cliente debe descomprimir los bytes. Esa operación suele ejecutarse dentro de una biblioteca nativa o un runtime, y por eso una aplicación puede depender de Brotli sin importarlo directamente.

La presencia del paquete, sin embargo, no prueba por sí sola que exista una vía explotable. Hay que comprobar qué versión se usa y si se procesan flujos no confiables.

Qué falla exactamente en CVE-2026-111497

Según el aviso de seguridad de Node.js, una transición inválida de tipo de bloque en el decodificador era interpretada como una necesidad temporal de recibir más datos, en lugar de rechazarse como error definitivo del formato.

Durante la descompresión incremental, esa interpretación permitía continuar añadiendo bytes a un búfer interno de ocho bytes más allá de sus límites. El resultado potencial es corrupción de memoria en el proceso.

Flujo Brotli recibido de una fuente no confiable
                       |
                       v
         Decodificador vulnerable
                       |
            Bloque malformado
                       |
                       v
    Error de formato tratado como "faltan datos"
                       |
                       v
       Escritura fuera del búfer
                       |
            Corrupción de memoria

Las consecuencias posibles incluyen cierre inesperado del proceso, divulgación de contenido de memoria y, en determinadas condiciones, ejecución de código. No son resultados automáticos ni equivalentes: dependen de la aplicación, del control que tenga el atacante y de las protecciones del entorno.

El boletín de Red Hat del 26 de octubre informa de demostraciones públicas de corrupción de memoria y denegación de servicio, pero indica que no se ha observado un exploit público y fiable de ejecución remota de código. Por eso conviene distinguir entre impacto potencial y explotación demostrada.

¿Qué versiones están afectadas?

El registro CVE identifica como vulnerables las ramas de Google Brotli:

RamaVersiones afectadasPrimera corrección de esa rama
1.0.x1.0.3 hasta 1.0.91.0.10
1.1.x1.1.01.1.1
1.2.x1.2.01.2.1

El proyecto Brotli publicó las correcciones. En instalaciones nuevas que utilizan esa línea, 1.2.1 o posterior es una opción corregida. Las distribuciones Linux pueden aplicar backports de seguridad sin adoptar el número de versión más alto: hay que consultar el aviso del proveedor.

Para Node.js, las versiones corregidas publicadas en el aviso del 21 de octubre son 22.23.4, 24.22.1 y 26.12.1. La solución consiste en instalar una versión mantenida y corregida de la rama utilizada, no simplemente actualizar un paquete independiente de Python.

Otros productos que integran su propio decodificador —por ejemplo navegadores, proxies, contenedores o aplicaciones compiladas— necesitan sus propias actualizaciones.

Cuándo hay exposición real

Un caso relevante sería un cliente HTTP que descarga una respuesta Brotli desde una fuente que puede ser controlada por un atacante; por ejemplo, una URL externa suministrada a un importador de contenidos o una API que acepta flujos comprimidos. La descompresión puede ejecutarse automáticamente antes de que los controles de la aplicación examinen los datos.

También pueden existir APIs explícitas de descompresión, como zlib.brotliDecompress() en Node.js.

No obstante, debemos evitar tres conclusiones apresuradas:

  • «Uso una herramienta que descarga vídeos, luego soy vulnerable». No necesariamente: depende del runtime, el decodificador, la configuración y la procedencia real de la respuesta.
  • «Tengo Brotli instalado, luego pueden entrar a mi servidor». Una instalación sin ruta alcanzable por datos no confiables no equivale a explotación.
  • «Existe riesgo de ejecución remota, luego ya se ha ejecutado código en sistemas reales». El potencial técnico no demuestra un compromiso.

La pregunta correcta es: ¿algún proceso nuestro descomprime Brotli controlado por un tercero usando una copia no corregida?

Auditoría rápida en Linux, Python y Node.js

Estos comandos son diagnósticos. No modifican servicios y no constituyen un escáner exhaustivo de vulnerabilidades.

# Paquetes gestionados por Debian/Ubuntu
dpkg-query -W '*brotli*' 2>/dev/null
apt-cache policy libbrotli1 python3-brotli

# Entorno Python desde el que se ejecuta la aplicación
python3 -m pip show Brotli brotlicffi

# Runtime Node.js
node --version
node -p "process.versions.brotli"

# Bibliotecas compartidas conocidas por el enlazador
ldconfig -p | grep -i brotli

Interpretación importante:

  • pip show examina solo el entorno Python seleccionado; hay que revisar los entornos virtuales realmente usados por los servicios.
  • process.versions.brotli identifica la versión incorporada, pero no demuestra por sí sola si una distribución ha incorporado un parche específico.
  • dpkg-query no detecta ruedas Python, binarios enlazados estáticamente ni bibliotecas dentro de imágenes de contenedor.
  • Las imágenes Docker deben reconstruirse con sus bases y dependencias corregidas y después desplegarse nuevamente.

Para inventarios fiables, conviene combinar gestores de paquetes, SBOM, avisos del proveedor y pruebas funcionales del flujo de descarga.

Remediación por orden de prioridad

  1. Identificar las rutas de entrada. Localizar endpoints, clientes HTTP, extractores y procesos que pueden descomprimir respuestas br de fuentes externas.
  2. Actualizar cada copia vulnerable. Instalar los paquetes corregidos de la distribución, actualizar las dependencias Python y usar un runtime Node.js con parche. En binarios y contenedores, reconstruir con las bibliotecas corregidas.
  3. Validar antes de desplegar. Probar descargas legítimas, tipos de contenido, respuestas comprimidas y límites de recursos. Reiniciar los procesos que cargaban bibliotecas antiguas.
  4. Mitigar mientras llega el parche. Donde la configuración lo permita, deshabilitar temporalmente la aceptación o descompresión de br proveniente de fuentes no confiables; comprobar el impacto funcional.
  5. Verificar el estado final. Confirmar qué versiones están efectivamente cargadas y que ya no se alcanzan rutas vulnerables.

Guía complementaria: si la actualización corregida todavía no está disponible o hay dependencias que conservar, explicamos cómo reducir la superficie de exposición en Linux bloqueando fwupd y PackageKit sin desactivar APT ni unattended-upgrades. Es una mitigación temporal, no un sustituto del parche.

No conviene ejecutar una actualización masiva sin inventario ni interrumpir un servicio productivo si puede aplicarse una remediación acotada y comprobada.

La lección de fondo

La descompresión es una frontera de confianza. Recibe bytes no verificados, transforma datos y suele operar a un nivel inferior al código que validará el documento resultante.

CVE-2026-111497 recuerda que la seguridad de un sistema no depende únicamente de validar URLs, HTML o JSON: también depende del código que interpreta la compresión, del runtime que lo incluye y de las copias embebidas que una actualización superficial puede dejar intactas.

La respuesta proporcional es clara: inventariar, comprobar exposición, actualizar, probar y verificar. Ni minimizar la corrupción de memoria ni asumir que toda instalación está comprometida.

Fuentes y lecturas adicionales