CVE-2026-111497: un fallo en Brotli, nueve entornos de ejecución y el agente Codex que lo encontró

Lo incómodo de CVE-2026-111497 es que no se trata de una sola vulnerabilidad en un solo producto. Es una escritura fuera de límites en el descompresor Brotli de Google, y el mismo error es accesible a través de al menos ocho runtimes y proxies separados que incorporan la biblioteca: Node.js, .NET y ASP.NET Core, Brotli y brotlicffi de Python, Bun, Envoy, Istio y la implementación de Go puro. La medición de Wiz sitúa el 91 % de los entornos de nube en riesgo y señala que el 82 % de ellos exponen Node.js públicamente. CISA lo ha añadido al catálogo de Vulnerabilidades Explotadas Conocidas, y Microsoft publicó un parche de emergencia para .NET y Visual Studio.

La segunda mitad de la historia es quién lo encontró: Khai Tran y Sylvie Mayer, de OpenAI Codex Security, según el informe de Wiz y los créditos upstream. Ese es un equipo de agentes de seguridad de IA, y la falla que encontró se encuentra en la biblioteca de descompresión más ampliamente integrada en la web.

Qué hace el bug

Brotli es lo que casi todos los stacks HTTP descomprimen cuando un servidor envía code>Content-Encoding: br/code>. Un flujo comprimido malformado provoca una escritura fuera de límites durante la descompresión, y la puntuación CVSS v4 es 9,2. El rango afectado es Brotli 1.0.3 hasta 1.2.0, corregido en 1.0.10, 1.1.1 y 1.2.1.

Lo que lo convierte en un programa en vez de un ticket es que la biblioteca está vendorizada, enlazada estáticamente o reimplementada en cada runtime, por lo que la corrección llega a través de un tren de lanzamiento diferente en cada caso — y a veces no llega en absoluto, porque la distribución estándar de un lenguaje tiene su propia copia.

La lista de parches, que es la parte útil

Todas las cifras que aparecen a continuación proceden del resumen de avisos de Wiz y de las notas de publicación de los respectivos proyectos, consultados el 30 de octubre de 2026.

• Google Brotli / libbrotli — afecta a 1.0.3–1.2.0, excluyendo los backports parcheados; corregido en 1.0.10, 1.1.1, 1.2.1.

• Python Brotli — afectado 1.0.3–1.2.0; corregido en 1.2.1. brotlicffi — afectado 1.0.3–1.2.0.x; corregido en 1.2.1.0.

• Node.js — afecta a las versiones 22.x, 24.x y 26.x; corregido en 22.23.4, 24.22.1 y 26.12.1.

• Bun — afectado en 1.0.21–1.4.3; corregido en 1.4.4.

• Envoy Proxy — afecta a 1.36.11, 1.37.7, 1.38.5 y 1.39.2; corregido en 1.36.12, 1.37.8, 1.38.6, 1.39.3 y 1.40.0.

• Istio — afectadas 1.29.0–1.29.8, 1.30.0–1.30.5, 1.31.0–1.31.1; corregido en 1.29.9, 1.30.6 y 1.31.2.

• andybalholm/brotli (Go) — afectado antes de v1.2.7; corregido en v1.2.7.

La fila de Node.js es la que decide la semana de la mayoría de las personas. Un servicio en 22.22.x queda expuesto a través de su pila HTTP incluso si su código de aplicación nunca menciona Brotli, porque la descompresión ocurre antes de que se invoque tu manejador. Eso también explica los tres nombres que la industria le atribuyó: Node2Shell para la ruta de Node, HTTP2Shell para la ruta del proxy documentada por Check Point, y Brotli2Shell de JFrog para el panorama más amplio.

Por qué "91%" es la cifra con la que hay que discutir

Las cifras de Wiz describen las infraestructuras en la nube de los clientes de Wiz, no internet. Un recuento de entornos con una biblioteca vulnerable en algún lugar dentro de ellos no es un recuento de servicios explotables, y la diferencia es grande: un Brotli empaquetado dentro de una aplicación de escritorio que nunca descomprime entradas no confiables es un hallazgo, no una vulnerabilidad. La versión útil de la estadística es más estrecha — servicios que aceptan entradas comprimidas de fuentes no confiables, lo que es esencialmente todo punto de conexión HTTP público que termina en code>br/code>.

Dos cosas hacen que la explotación sea plausible en lugar de teórica: el hecho de que CISA la haya añadido al catálogo KEV implica que se ha observado explotación, y los operadores de honeypots han registrado intentos. Cuando una vulnerabilidad pasa a la columna de las explotadas en la naturaleza, el plazo para aplicar el parche deja de ser tu calendario de control de cambios y pasa a ser el de otra persona.

El descubrimiento es la parte con una vida media más larga.

El equipo de seguridad de un modelo de frontera encontró un error de seguridad de memoria en una biblioteca de descompresión que ha sido leída por miles de personas durante una década. No es una historia sobre un proveedor que se vuelve astuto; es una declaración sobre cobertura. El análisis estático se ha dirigido a Brotli durante años, existen arneses de fuzzing, y el error sobrevivió a ambos — mientras un agente diseñado para leer código con intención lo encontró y produjo una corrección que upstream aceptó.

La asimetría funciona en ambos sentidos. La misma capacidad que encuentra esta clase de error la encontrará en el código que despliegas. La cuestión para cualquiera que trabaje con programación agéntica no es si el agente puede detectar una escritura fuera de límites; es si el hallazgo llega a ti antes de que llegue a otra persona.

Qué hacer, en el orden que importa

• Aplica parches a los runtimes que realmente ejecutas. La lista de bibliotecas de arriba es la fuente; empieza por los que terminan el tráfico público.

• Luego, busca copias vendorizadas. Las imágenes base de contenedores, los binarios estáticos, las compilaciones WASM y los wheels de lenguaje llevan cada uno su propio Brotli, y ninguno de ellos aparecerá en una auditoría del gestor de paquetes de la aplicación. Un escáner de inventario a nivel de repositorio publicado esta semana recorre un sistema de archivos y evalúa cada copia de Node, Bun y Brotli que encuentra, lo cual es un punto de partida más rápido que inventar uno.

• Recompilar en lugar de parchear, siempre que sea posible. Reemplazar una biblioteca enlazada estáticamente dentro de un artefacto compilado es donde la gente distribuye accidentalmente un binario a medio corregir.

• Si ejecutas Envoy o Istio como perímetro, considera las correcciones del proxy como la máxima prioridad del conjunto: el proxy descomprime en nombre de todo lo que está detrás de él.

• Revise su parque de .NET por separado. El parche de Microsoft cubre .NET y Visual Studio, y la versión correcta es una actualización del entorno de ejecución, no un cambio en la referencia al paquete.

Dónde se sitúa esto para nuestros lectores

La mayor parte de lo que cubre este blog es la capacidad, el precio y el enrutamiento de los modelos. Esto tiene cabida aquí por una línea: el defecto lo encontró un agente de IA, y la clase de sistema que encuentra ese tipo de errores es la misma clase de sistema que nuestros lectores están integrando en sus pipelines. Un agente de escaneo de repositorios que se ejecuta en CI sobre tus dependencias ahora es un control de seguridad, y es el mismo entorno de ejecución de agentes que escribe tu código.

El Agent Firewall de OrcaRouter evalúa las llamadas a herramientas y a MCP antes de que se ejecuten, que es el control que limita el radio de impacto de un agente; no hace que los hallazgos de un agente sean correctos, y nada de esta CVE constituye una afirmación de que enrutar un modelo reduce el riesgo de la cadena de suministro. Lo útil que sacar de la semana es más limitado y verificable: si le diste a un agente acceso de lectura al repositorio para encontrar errores, verifica que sus parches propuestos estén fijados, y verifica que el runtime que hay debajo de tu propia pila haya superado la 1.0.3–1.2.0.

El patrón que conviene recordar es que la vulnerabilidad estaba en código que nadie eligió. Brotli llegó como dependencia transitiva de una funcionalidad del entorno de ejecución, se corrigió en ocho lugares con calendarios distintos y seguirá llegando dentro de imágenes base que se construyeron antes de esta semana. La respuesta ante la cadena de suministro consiste, sobre todo, en la disciplina de encontrar las copias que no instalaste.

Nota de fuentes: la matriz de versiones afectadas y corregidas, la lista de entornos de ejecución y las cifras de exposición del 91 %/82 % proceden del resumen del aviso de Wiz consultado el 30 de octubre de 2026, y las versiones corregidas son las publicaciones propias de los proyectos. La puntuación CVSS v4 de 9,2 procede del registro CVE. El crédito del descubrimiento a Khai Tran y Sylvie Mayer, de OpenAI Codex Security, procede del informe de Wiz y de los créditos upstream. El listado de CISA en KEV y el parche de .NET de Microsoft son anuncios de las respectivas organizaciones; ninguno de los dos se consultó aquí como documento primario más allá del resumen del aviso. La descripción del escáner de inventario es la descripción propia de un proyecto de terceros en GitHub.