Izkuna
Volver al blog
Luis Martinez

Node2Shell: cuando el decodificador Brotli se convierte en una vía de ejecución remota

CVE-2026-111497 es una escritura fuera de límites en el decodificador Brotli incluido en Node.js y .NET. Hay versiones corregidas; lo difícil es encontrar cada runtime.

Brotli Node.js .NET Gestión de vulnerabilidades
Node2Shell: cuando el decodificador Brotli se convierte en una vía de ejecución remota

Una librería de compresión no suele estar en el registro de riesgos de un consejo. CVE-2026-111497 recuerda que debería estarlo.

El fallo es una escritura fuera de límites en el decodificador Brotli, activada por entrada comprimida malformada. Puede corromper memoria y, en el peor caso, permitir ejecución remota de código. La Agencia de Ciberseguridad de Singapur lo califica con 9,8 sobre 10 y describe a un atacante sin autenticación que envía un flujo Brotli manipulado para corromper la memoria del decodificador o exponer información sensible. Los investigadores lo apodaron "Node2Shell"; algunos análisis también lo llaman HTTP2Shell.

Quién publicó correcciones

  • Node.js publicó versiones parcheadas el 21 de octubre de 2026: 22.23.4, 24.22.1 y 26.12.1. Las líneas sin soporte 25.x, 23.x, 20.x y anteriores no recibirán corrección.
  • Bun corrigió el problema en 1.4.4.
  • Microsoft publicó actualizaciones .NET fuera de ciclo el 25 de octubre de 2026. El aviso de Singapur enumera .NET 8, 9, 10 y 11 como afectados.
  • Las versiones afectadas de la librería Brotli subyacente van de la 1.0.3 a la 1.2.0. NVD señala 1.0.10, 1.1.1 o 1.2.1 según la rama.

La suposición peligrosa es que "usamos Node.js" basta para delimitar el alcance. El decodificador también está incluido en runtimes, imágenes base de contenedores, capas serverless y binarios de terceros.

Cómo llega el atacante al decodificador

La explotación requiere que la aplicación descomprima datos Brotli controlados por el atacante. Tres rutas comunes:

  1. Cuerpos de solicitud comprimidos. Express 5 y body-parser 2.x decodifican Content-Encoding: br. Un servidor HTTP de Node sin framework no lo hace, pero muchos frameworks y proxys sí.
  2. Solicitudes salientes. El fetch() de Node descomprime automáticamente las respuestas Brotli. Si tu servidor consulta una URL que un atacante puede influir, la respuesta pasa por el decodificador.
  3. Uso directo de node:zlib. Cualquier código que llame a las funciones Brotli con entrada no confiable entra en el alcance.

Node.js empaquetado por una distribución puede enlazar la librería Brotli del sistema en lugar de la incluida. Eso cambia qué componente debes actualizar, así que verifica en lugar de asumir.

Estado de explotación, con precisión

Node.js no tenía explotación confirmada en la naturaleza cuando publicó los parches. Sin embargo, para el 30 de octubre, la agencia de Singapur reportó una prueba de concepto pública y afirmó que el fallo "presuntamente se está explotando activamente". Eso basta para tratar los servicios expuestos a internet como urgentes.

Una lista de verificación

  1. Encuentra cada runtime. Ejecuta node --version en hosts, imágenes de contenedor, runners de CI y capas serverless. Revisa .nvmrc, Dockerfiles y lockfiles en busca de versiones ancladas.
  2. Actualiza a 22.23.4, 24.22.1, 26.12.1 o posterior. Sal de las líneas sin soporte en lugar de buscar un backport.
  3. Reconstruye y redespliega las imágenes. Cambiar una etiqueta sin reconstruir puede dejar el binario antiguo en la caché de capas, y un node:22.23.3-alpine anclado sigue vulnerable.
  4. Actualiza .NET y Bun donde formen parte del stack, y confirma que la compilación parcheada es la que se ejecuta.
  5. Revisa servicios de terceros. Una API de proveedor que descomprime entrada comprimida por ti forma parte de tu cadena de suministro.
  6. Usa controles de borde solo como solución temporal. Rechazar Content-Encoding: br en el proxy reduce la exposición, pero no cubre las respuestas Brotli que tu aplicación descarga de otros sitios.

Por qué esta clase de fallo sigue apareciendo

Brotli, zlib, analizadores de imágenes, generadores de PDF, analizadores XML: los componentes que procesan entrada no confiable suelen estar escritos en lenguajes con memoria insegura y se actualizan con menos visibilidad que el framework de la aplicación. Además, a menudo se incluyen en el paquete en lugar de instalarse, lo que los oculta de los escáneres de dependencias.

Para un equipo pequeño, el control viable es inventario más una regla: todo lo que analiza datos controlados por un atacante se parchea con el mismo calendario que el sitio público, no con uno separado y más lento.

Dónde encaja una auditoría

La Auditoría Web Express de Izkuna revisa la aplicación, sus dependencias y la configuración del servidor en cinco días al precio de lanzamiento actual de USD 600. Si un componente requiere una corrección coordinada, el Acompañamiento en Remediación ayuda a tu equipo a cerrarla, y el Retest / Verificación de Remediación confirma que el nuevo runtime es el que realmente atiende el tráfico.

La compresión debería ser invisible para los usuarios. No debería ser invisible para tu inventario de activos.

Fuentes

Si no sabes qué runtimes usan tus servicios, empieza con un diagnóstico gratuito de 30 minutos.