Fallo en el decodificador Brotli de Node.js permite ejecución remota de código en compilaciones oficiales

Investigadores de seguridad de Imperva han demostrado una vulnerabilidad crítica de ejecución remota de código (RCE) en el tiempo de ejecución oficial de Node.js. Al alimentar al decodificador integrado con datos de compresión Brotli específicamente manipulados, lograron ejecutar código arbitrario en una compilación estándar de Linux arm64 de Node.js 24.22.0. El equipo de Node.js divulgó el fallo, rastreado como CVE-2026-111497, y publicó correcciones el 21 de octubre, instando a los desarrolladores a actualizar cualquier aplicación que procese flujos Brotli no confiables.

Qué ocurrió

La demostración, bautizada como "Node2Shell", marca una escalada significativa respecto a intentos anteriores de prueba de concepto. Investigadores previos solo habían logrado la ejecución de código en compilaciones de prueba deliberadamente debilitadas, mientras que las compilaciones estándar simplemente se bloqueaban o permitían lecturas limitadas de memoria. Sin embargo, el equipo de Imperva ejecutó su exploit en una imagen oficial de Node.js 24.22.0 sin depuradores ni modificaciones personalizadas. Aunque el exploit no era determinista y requirió varios intentos para tener éxito en su entorno Linux arm64, confirmó que la ejecución completa de código es posible en entornos de producción.

Esta vulnerabilidad afecta a una amplia gama de aplicaciones porque reside en el decodificador Brotli incluido con el propio Node.js. Impacta en las líneas de lanzamiento activas 22.x, 24.x y 26.x. El riesgo está presente siempre que una aplicación decodifique datos comprimidos con Brotli, lo cual puede ocurrir de dos maneras principales: al leer una respuesta comprimida mediante la API fetch() integrada, o cuando un middleware decodifica explícitamente un cuerpo de solicitud comprimido. Por ejemplo, los analizadores de cuerpo de Express 5 ahora manejan Brotli junto con gzip y deflate, lo que significa que muchos servicios backend modernos están expuestos si procesan solicitudes entrantes de fuentes no confiables.

Imperva probó este vector utilizando Express 5.0.0 a 5.3.0 y body-parser 2.0.0 a 2.3.0, reproduciendo la ejecución de código a través de ambas rutas de solicitud y respuesta. Un servidor HTTP básico de Node.js no es vulnerable por defecto a menos que utilice middleware o llamadas explícitas para decodificar el cuerpo. Hasta el 22 de octubre, no había informes de explotación activa en el mundo real, pero la disponibilidad de una prueba de concepto funcional en compilaciones oficiales aumenta la urgencia de aplicar parches.

Cómo funciona

La causa raíz radica en cómo el decodificador Brotli integrado maneja transiciones de estado inválidas dentro de un flujo comprimido. Un flujo Brotli anuncia los tipos de bloques que utilizará a medida que avanza la decodificación. En la entrada maliciosa creada por Imperva, el flujo alcanzó un cambio de bloque que su propia estructura excluía explícitamente como imposible. En lugar de rechazar esta contradicción, el decodificador vulnerable la interpretó como una solicitud de más entrada y continuó procesando en un estado inválido.

Cuando el decodificador continúa en este estado corrupto, falla al aplicar comprobaciones de límites adecuadas. Las pruebas realizadas con un sanitizador de memoria revelaron que este error lógico conduce a una escritura fuera de límites, donde los datos se escriben más allá de los límites previstos del búfer. Esta corrupción de memoria crea la oportunidad para que un atacante inyecte y ejecute código. El proyecto Node.js resolvió el problema importando un parche upstream de la biblioteca Brotli. Esta corrección garantiza que el decodificador se detenga inmediatamente y devuelva un error de formato al encontrar tales contradicciones estructurales imposibles, evitando que ocurra nunca el estado inválido.

Detalles clave

• ID de Vulnerabilidad: CVE-2026-111497 afecta al decodificador Brotli integrado en Node.js.
• Versiones Afectadas: Las líneas de lanzamiento activas 22.x, 24.x y 26.x son vulnerables; las versiones obsoletas como 20.x no reciben correcciones.
• Vector de Ataque: Datos Brotli manipulados enviados a través de cuerpos de solicitud HTTP (decodificados por middleware) o recibidos a través de respuestas de fetch().
• Fiabilidad del Exploit: La prueba de concepto de Imperva requirió múltiples intentos para tener éxito en Linux arm64 y no fue probada en otras arquitecturas.
• Estado de la Corrección: Los parches fueron publicados el 21 de octubre; la versión 24.22.1 rechaza los datos maliciosos de forma segura.
• Sin Solución Alternativa en Tiempo de Ejecución: El aviso indica que no hay ningún cambio de configuración dentro de Node.js para mitigar esto; la actualización es el único remedio.

Por qué importa

Para ingenieros de software y líderes técnicos, esta vulnerabilidad destaca un riesgo oculto en las cadenas de dependencias. Dado que el fallo está en el tiempo de ejecución mismo y no en un paquete npm de terceros, las herramientas estándar de inventario de paquetes pueden no detectarlo. Los desarrolladores a menudo asumen que las bibliotecas de compresión son utilidades seguras de bajo nivel, pero este incidente demuestra que pueden ser un camino directo hacia la ejecución remota de código. Los servicios que actúan como proxy de APIs externas o aceptan cargas de usuario están particularmente en riesgo si descomprimen contenido automáticamente sin una validación estricta.

La falta de una solución alternativa en tiempo de ejecución significa que los equipos operativos no pueden simplemente activar una bandera de función para mantenerse seguros. Si su infraestructura depende de imágenes de contenedores o artefactos precompilados, debe asegurarse de que el binario subyacente de Node.js esté actualizado. Esto a menudo requiere reconstruir y redesplegar servicios, no solo reiniciarlos. Además, plataformas como Vercel han añadido reglas de firewall de aplicaciones web para bloquear ataques entrantes, pero estas no protegen contra respuestas Brotli maliciosas obtenidas por su servidor desde otros hosts, dejando la ruta saliente vulnerable hasta que se aplique el parche.

Qué puede hacer

• Actualice todas las instancias de Node.js a las últimas versiones parcheadas en las líneas 22.x, 24.x o 26.x inmediatamente.
• Audite sus imágenes de contenedores y pipelines de CI/CD para asegurar que el binario base de Node.js esté actualizado, no solo el código de la aplicación.
• Identifique servicios que usen Express 5 o body-parser y acepten cuerpos de solicitud no confiables, priorizando su parcheo.
• Revise el uso de la API fetch() integrada para asegurar que las respuestas de servidores externos no confiables sean manejadas con precaución.
• Migre cualquier aplicación que aún ejecute versiones obsoletas como 20.x a una línea de lanzamiento compatible para recibir correcciones de seguridad.
• Monitoree los registros buscando bloqueos inusuales o errores de memoria en servicios que manejen datos comprimidos, lo cual puede indicar intentos de explotación.