CVE-2026-111497: la vulnerabilidad de Brotli que ya está siendo explotada

CVE-2026-111497 —conocida también como Broccoli2Shell o Node2Shell— es una vulnerabilidad crítica en Brotli, la librería de compresión de Google que prácticamente todo el tráfico web usa sin que nadie la note. Fue divulgada el 21 de octubre de 2026 y, a diferencia de muchas fallas que se reportan como «potencialmente explotables», esta ya tiene explotación activa confirmada: CISA la agregó a su catálogo de vulnerabilidades explotadas (KEV) el 27 de octubre.

Qué es exactamente

Es un fallo de escritura fuera de los límites de memoria en el decodificador de Brotli: cuando el decodificador procesa un bloque de datos comprimidos construido de forma maliciosa, escribe más allá de la memoria que tenía asignada. Un atacante remoto, sin ninguna credencial, puede enviar ese flujo de datos malformado y provocar —según el caso— fuga de memoria, caída de la aplicación o, en el peor escenario, ejecución de código arbitrario con los permisos del proceso afectado.

Por qué es más grande de lo que suena

Brotli no es un producto que alguien instala a propósito: es una pieza de infraestructura que viaja embebida dentro de muchísimo software distinto. Eso significa que un sistema puede estar expuesto aunque nadie en el equipo que lo mantiene sepa que Brotli forma parte de su stack.

• Node.js, donde se identificó originalmente el problema.
• Microsoft .NET y PowerShell — Microsoft llegó a publicar una actualización de emergencia fuera de su calendario habitual.
• Bun, Envoy Proxy e Istio — es decir, puertas de entrada y mallas de servicios que atraviesan buena parte del tráfico de una infraestructura moderna.
• Los paquetes de Python brotli y brotlicffi, y la librería en Go andybalholm/brotli.
• Cualquier binario o contenedor que incluya una copia estática de la librería C original de Google (libbrotli), incluso sin que el equipo de desarrollo la haya elegido de forma consciente.

Muchos clientes y frameworks HTTP activan la descompresión Brotli de forma automática cuando el servidor remoto la ofrece. Eso quiere decir que una aplicación puede quedar expuesta simplemente por aceptar una respuesta HTTP comprimida — sin que el código de la aplicación mencione Brotli en ninguna parte.

Versiones corregidas

• Brotli / libbrotli: 1.0.10, 1.1.1 y 1.2.1 (según la rama).
• Node.js: 22.23.4, 24.22.1 y 26.12.1.
• Python brotli / brotlicffi: 1.2.1 / 1.2.1.0.
• Bun: 1.4.4. Envoy Proxy: 1.36.12 / 1.37.8 / 1.38.6 / 1.39.3 / 1.40.0. Istio: 1.29.9 / 1.30.6 / 1.31.2.
• andybalholm/brotli (Go): v1.2.7.

Qué hacer

1. Haz inventario antes que nada. No alcanza con revisar tu propio código: hay que rastrear dependencias transitivas, imágenes base de contenedores, y binarios estáticos que puedan traer una copia embebida de Brotli.
2. Prioriza lo expuesto a internet. Cualquier servicio que reciba tráfico HTTP sin autenticación previa —APIs públicas, proxies, balanceadores— es el blanco más directo para este tipo de falla.
3. Actualiza a las versiones corregidas de la lista anterior: librería Brotli, runtime (Node.js, .NET), y cualquier proxy o malla de servicios (Envoy, Istio) que esté en el camino.
4. Reconstruye y redespliega, no solo actualices el paquete: hay que regenerar imágenes de contenedores y archivos de bloqueo de dependencias, reiniciar los procesos, y confirmar que la versión corregida es la que realmente queda cargada en memoria.
5. Si no puedes parchar de inmediato, una mitigación temporal —nunca un sustituto del parche— es bloquear o rechazar las solicitudes con compresión Brotli a nivel de proxy o firewall hasta completar la actualización.

Con explotación activa ya confirmada y una superficie de exposición que incluye gran parte de la infraestructura web moderna sin que los equipos lo sepan, este es uno de esos casos donde «ya lo vemos después» tiene un costo real. Vale la pena revisar el inventario de dependencias hoy, no después del próximo incidente.