Un único error en la biblioteca de compresión Brotli de Google —identificado como CVE-2026-111497 y apodado Node2Shell, Brotli2Shell y HTTP2Shell— permite a un atacante corromper la memoria de cualquier programa que descomprima datos Brotli controlados por el atacante, lo que puede desembocar en la ejecución remota de código. Dado que Brotli está integrado en Node.js, .NET, Python, Bun y una larga lista de otros programas, un solo fallo en el origen se convirtió en una carrera por parchear todo el stack a finales de octubre de 2026. Si tu servicio acepta un cuerpo de petición con Content-Encoding: br o decodifica Brotli desde cualquier fuente no confiable, necesitas parchear.
Esto no es otro CVE limitado a un único producto. La vulnerabilidad de Brotli reside en el decodificador C compartido que decenas de runtimes incorporan, así que la pregunta interesante no es "¿está afectado Node.js?" (lo está), sino "¿cuáles de las cosas que ejecuto enlazan silenciosamente la misma biblioteca?". Este artículo traza todo el radio de impacto y te da la versión corregida de cada ecosistema en una sola tabla.
¿Qué es CVE-2026-111497?
CVE-2026-111497 es una escritura fuera de límites en el decodificador Brotli. Según las notas de la versión de seguridad de Node.js, el decodificador en streaming seguía añadiendo bytes de entrada a un búfer interno de ocho bytes sin comprobar los límites, de modo que datos comprimidos con Brotli especialmente diseñados desbordan ese búfer y corrompen la memoria del proceso. Los resultados prácticos son un fallo, la divulgación de la memoria del proceso o, en el peor de los casos, la ejecución remota de código. Google puntuó el fallo con un 9.2 según CVSS v4.0, mientras que la Agencia de Ciberseguridad de Singapur citó una puntuación CVSS v3.1 de 9.8; en cualquier caso, crítica. La única condición previa es que una aplicación vulnerable descomprima datos Brotli en los que un atacante pueda influir, algo que es un patrón muy habitual: Brotli (br) es una codificación de contenido HTTP estándar compatible con todos los navegadores y CDN convencionales.
Por qué un solo error afecta a tantos productos
Brotli se distribuyó como una biblioteca C pequeña y rápida que los runtimes de las aplicaciones incorporan directamente en lugar de depender de ella a nivel del sistema operativo. Ese diseño es la razón por la que cada proyecto tuvo que volver a publicar la corrección en vez de parchearla una sola vez. El proveedor de seguridad Field Effect señala que el fallo alcanza a múltiples ecosistemas a la vez, y el aviso de Tenable enumera un radio de impacto que incluye Python, Bun, .NET, brotli4j de Java, el proxy Envoy y la malla de servicios Istio, además de herramientas de datos como FFmpeg, Apache Arrow y ClickHouse. Es la misma forma de "un fallo, muchos stacks" que cubrimos con la HTTP/2 Bomb que tumbó nginx, Apache e IIS: una primitiva compartida en la que todos confiaban, fallando en todas partes de forma simultánea. También guarda similitudes con el riesgo a nivel de dependencias detrás de la crisis de la cadena de suministro de npm de 2026: el código que nunca elegiste instalar sigue siendo tu superficie de ataque.
Matriz de parches: versiones corregidas por ecosistema
Actualiza a las versiones indicadas a continuación. Si ejecutas contenedores o imágenes de CI, reconstrúyelos: una imagen base parcheada es la forma más rápida de corregir los runtimes incorporados de una sola vez.
| Ecosistema | Versión(es) corregida(s) | Notas |
|---|---|---|
| Google Brotli (biblioteca C) | 1.0.10, 1.1.1, 1.2.1 | El origen del error; todo lo demás vuelve a incorporar esto |
| Node.js | 22.23.4, 24.22.1, 26.12.1 | Corregido a través de node:zlib en la versión del 21 de octubre; 20.x ha llegado al fin de su vida útil y no se parcheará |
| .NET | 8.0.33, 9.0.22, 10.0.14 | Aplica la actualización del runtime de octubre |
| Python (brotli / brotlicffi) | 1.2.1 / 1.2.1.0 | Habitual en clientes HTTP que negocian la codificación br |
| Bun | 1.4.4 | Incorpora su propio decodificador Brotli |
| brotli4j, Envoy, Istio, FFmpeg, Apache Arrow, ClickHouse, PHP para Windows | Según el aviso del proveedor | Todos enlazan el mismo decodificador: revisa las notas de versión de cada proyecto |
¿Estoy realmente expuesto?
Instalar un runtime vulnerable no es lo mismo que ser explotable. La prueba de exposición es sencilla: ¿descomprime tu código en algún momento datos Brotli que un atacante pueda suministrar? Hazte estas tres preguntas, en orden:
- ¿Aceptas cuerpos de petición en Brotli? Una API o un proxy que respeta
Content-Encoding: bren las peticiones entrantes es la vía de exposición clásica: el atacante controla directamente los bytes comprimidos. - ¿Obtienes y descomprimes contenido remoto? Los clientes HTTP del lado del servidor, los consumidores de webhooks y los scrapers que permiten que el servidor envíe respuestas codificadas con
brestán expuestos si el extremo remoto no es de confianza. - ¿Descomprimes archivos subidos por usuarios o almacenados a través de una ruta Brotli? Las canalizaciones de compilación, los procesadores de documentos y las herramientas de datos (Arrow, ClickHouse, FFmpeg) que ingieren flujos
.brcuentan.
Si la respuesta a las tres es no —por ejemplo, si solo comprimes respuestas salientes y nunca decodificas Brotli no confiable—, tu riesgo práctico es menor, pero parchea de todos modos. El análisis de Rapid7 subraya que las rutas del decodificador son fáciles de alcanzar de forma indirecta a través de bibliotecas que no sabías que negocian br, así que "no creo que use Brotli" no es una suposición segura.
Cronología: una brecha de ocho meses
El detalle más incómodo es la demora. La corrección se confirmó en el repositorio de Brotli en el origen el 27 de febrero de 2026, pero las versiones corregidas de la biblioteca no se publicaron hasta el 21 de octubre de 2026: aproximadamente ocho meses durante los cuales el parche estuvo en el historial público del código fuente mientras los binarios publicados seguían siendo vulnerables. Datadog Security Labs reprodujo el error con el nombre de Node2Shell y, para cuando la divulgación coordinada llegó el 30 de octubre, ya había una prueba de concepto pública y el fallo estaba siendo explotado activamente, según se informó. Un commit público en el origen es una hoja de ruta para los atacantes; la ventana entre "corregido en el código fuente" y "distribuido a los usuarios" es exactamente donde este fallo se volvió peligroso. Es la misma lección sobre la latencia de los parches que hay detrás de nuestro artículo sobre la peor semana de parches de 2026.
Qué hacer ahora
Trata esto como una tarea para el mismo día en cualquier servicio expuesto a internet. Parchea los runtimes a las versiones de la tabla, reconstruye y vuelve a desplegar las imágenes de contenedor para que las copias incorporadas se actualicen, y reinicia las cargas de trabajo: un proceso en memoria sigue ejecutando el decodificador vulnerable antiguo hasta que se reinicia. Después de parchear, revisa los registros de acceso y de peticiones en busca de las rutas expuestas mencionadas arriba; los exploits de corrupción de memoria suelen dejar bucles de fallos o reinicios anómalos antes de tener éxito. Si gestionas tu propia infraestructura, nuestra lista de verificación de la primera hora segura de un VPS cubre la higiene de registro y actualización que convierte el próximo incidente de este tipo en un parcheo rutinario en lugar de en una emergencia.
Preguntas frecuentes
¿Se está explotando CVE-2026-111497?
Hay una prueba de concepto disponible públicamente y, según se informa, la vulnerabilidad está siendo explotada activamente desde finales de octubre de 2026. Combinado con la gravedad crítica y la enorme base instalada, eso lo sitúa de lleno en el terreno de "parchea ya".
¿Qué versiones de Node.js están corregidas?
Node.js 22.23.4, 24.22.1 y 26.12.1, publicadas el 21 de octubre de 2026. Node.js 20.x llegó al fin de su vida útil el 30 de abril de 2026 y no recibirá una corrección: abandónala.
Solo comprimo respuestas, nunca descomprimo Brotli. ¿Estoy a salvo?
Tu riesgo directo es menor porque el error está en el decodificador, no en el codificador. Pero las bibliotecas y los clientes HTTP pueden negociar y decodificar br sin que te des cuenta, así que parchea de todos modos en lugar de confiar en esa suposición.
¿Parchear el sistema operativo lo soluciona?
Normalmente no por sí solo. La mayoría del software afectado incorpora su propia copia de Brotli, así que debes actualizar cada runtime (Node.js, .NET, Bun, paquetes de Python) y reconstruir las imágenes de contenedor: una simple actualización de un paquete del sistema operativo no refrescará una biblioteca incorporada.
Sources
- Node.js — Versiones de seguridad de octubre de 2026: las versiones parcheadas oficiales (22.23.4, 24.22.1, 26.12.1), el mecanismo de escritura fuera de límites y la publicación de los 10 CVE.
- Tenable — Preguntas frecuentes sobre Brotli2Shell (CVE-2026-111497): puntuación CVSS v4.0 9.2, ecosistemas afectados y versiones corregidas de Brotli/Python/Bun/.NET.
- Datadog Security Labs — Node2Shell: reproducción técnica y la cronología de la corrección de febrero a octubre de 2026.
- Rapid7 — Escritura crítica fuera de límites en el decodificador Brotli de Node.js: análisis de la exposición y por qué las rutas del decodificador son fáciles de alcanzar de forma indirecta.
- CSA Singapur — Explotación activa de una vulnerabilidad crítica de Brotli: puntuación CVSS v3.1 9.8, estado de explotación activa y de la PoC, productos afectados.
- Field Effect — La vulnerabilidad de Brotli afecta a múltiples ecosistemas de software: el radio de impacto que abarca múltiples ecosistemas.
Waqas Ahmed Waseer
Waqas Ahmed Waseer es desarrollador y creador de automatizaciones con más de 8 años construyendo sistemas en producción que usan más de 100.000 personas. Crea SaaS multiinquilino a medida, automatización con IA (n8n, flujos LLM, bots de WhatsApp) e infraestructura de hosting (WHM/cPanel, CloudLinux), y es el creador de WaSphere, FlowMaticX y la marca de hosting WaseerHost. Más de 100 proyectos entregados para pymes, agencias y startups financiadas.
