Vulnerabilidad de Brotli en Node.js: cómo quedan expuestas las aplicaciones y qué deben comprobar los desarrolladores

Ilustración de TechiesJournal sobre la vulnerabilidad. El decodificador vulnerable y el decodificador corregido de Node.js tratan de forma distinta los mismos datos comprimidos malformados.

Una parte crítica de la seguridad de una aplicación puede estar dentro de código que sus desarrolladores nunca tocan directamente. Las versiones de seguridad de Node.js de octubre de 2026 muestran por qué entender el comportamiento del entorno de ejecución (runtime) importa tanto como actualizar las dependencias de la aplicación.

Una respuesta comprimida de una API puede llegar a código nativo

Imagina un servicio de Node.js que obtiene información de una API externa. La aplicación hace una solicitud HTTP corriente, recibe una respuesta comprimida y procesa los datos devueltos. Nada en ese flujo parece inusual.

Entre la recepción de la respuesta y el uso de su contenido, puede que el entorno de ejecución tenga que descomprimirla. Si la respuesta usa Brotli, ese trabajo llega a un decodificador implementado en código nativo. Supón que los datos comprimidos están malformados a propósito y que el decodificador los gestiona de forma incorrecta.

Ese es el problema de seguridad detrás de CVE-2026-111497, una vulnerabilidad de gravedad alta divulgada como parte de las versiones de seguridad de Node.js del 21 de octubre de 2026. El fallo puede hacer que el decodificador Brotli incluido en Node.js escriba fuera de un búfer de memoria interno. Según el aviso oficial de Node.js, las consecuencias pueden incluir caídas del proceso, divulgación de memoria o ejecución remota de código. Posteriormente, investigadores de Imperva demostraron la ejecución de código con datos Brotli manipulados contra una compilación oficial vulnerable de Node.js.

Para los desarrolladores y los equipos de ingeniería, la pregunta importante no es simplemente si su aplicación usa Node.js. Es si datos comprimidos no confiables pueden llegar al decodificador vulnerable y si la versión de Node.js que realmente se ejecuta en su entorno tiene aplicado el parche.

Node.js publicó diez correcciones de seguridad el 21 de octubre

El 21 de octubre, el proyecto Node.js publicó actualizaciones de seguridad para tres líneas de versiones con soporte. Las líneas 22.x y 24.x son versiones con soporte a largo plazo (LTS), y 26.x es la línea Current.

La primera versión corregida de Node.js para cada línea con soporte

Línea de versiones de Node.js	Versión de seguridad
22.x LTS	22.23.4
24.x LTS	24.22.1
26.x Current	26.12.1

El anuncio abordó diez CVE relacionadas con la seguridad de memoria, la validación de certificados TLS, la gestión de DNS, la aleatoriedad criptográfica, la reutilización de conexiones HTTP, el procesamiento de ZIP y los permisos del sistema de archivos. También actualizó dependencias incluidas, entre ellas c-ares, OpenSSL, SQLite, Undici y el almacén de certificados de CA. La clasificación de gravedad más alta asignada por el proyecto Node.js fue alta. El Hong Kong Computer Emergency Response Team Coordination Centre también publicó un boletín de seguridad el 22 de octubre en el que recomienda actualizar a las versiones corregidas.

Una vulnerabilidad destaca por sus posibles consecuencias y por la evidencia técnica posterior: CVE-2026-111497, que afecta al decodificador Brotli. El resto de la versión de seguridad también importa, así que los equipos deben aplicar la actualización completa en lugar de intentar corregir solo una vulnerabilidad.

Brotli es un formato de compresión integrado en Node.js

Cuando un servidor envía información por una red, la compresión puede reducir la cantidad de datos transferidos. Una respuesta de API con texto repetitivo puede necesitar menos bytes una vez comprimida, y la aplicación que la recibe la descomprime para recuperar la información original. Brotli es uno de los formatos de compresión que se usan con este fin y suele identificarse por la codificación de contenido HTTP br.

Node.js incluye compresión y descompresión Brotli a través de su módulo node:zlib. Las aplicaciones pueden llegar a esa funcionalidad directamente, o indirectamente mediante componentes que procesan datos comprimidos. Puede que un desarrollador nunca escriba código que llame explícitamente a una función de descompresión Brotli y que, aun así, la aplicación use una a través de la gestión de respuestas HTTP o de un middleware de cuerpo de solicitud. Un middleware es código que procesa una solicitud antes de que la vea el manejador propio de la aplicación.

La vulnerabilidad está dentro del decodificador, no en la lógica de negocio de la aplicación.

Un cambio de bloque no válido permitía al decodificador escribir más allá de su búfer

Un decodificador procesa los datos comprimidos según las reglas que define el formato de compresión. A medida que lee la entrada, sigue el estado del flujo comprimido, incluido qué bloques y tipos de bloque son válidos en un punto concreto. Si el flujo contiene una transición no válida, el decodificador debería rechazarla.

El decodificador Brotli vulnerable no siempre hacía esa distinción correctamente. Según el aviso de Node.js, un cambio de bloque no válido podía tratarse como si el decodificador simplemente necesitara más entrada. En lugar de devolver un error de formato permanente, el procesamiento podía continuar. Esa gestión incorrecta del estado permitía que el decodificador en streaming siguiera añadiendo bytes a un búfer interno de ocho bytes más allá de su límite previsto.

Se trata de una escritura fuera de límites: un programa escribe datos más allá de la región de memoria destinada a contenerlos. Un defecto así puede corromper la memoria del proceso. Según las circunstancias, las consecuencias pueden ir desde una caída hasta una vulneración de seguridad más grave. El aviso de Node.js atribuye la notificación del fallo a Khai Tran y Sylvie Mayer, investigadores de OpenAI Codex Security.

La corrección de Brotli en el proyecto original cambia la forma en que las funciones del decodificador identifican y propagan los errores de formato no válido. Una transición de bloque imposible se notifica como error en lugar de confundirse con una petición de más entrada. En la práctica, la corrección restablece un límite importante: los datos comprimidos no válidos no deben hacer que el decodificador siga procesando en un estado inseguro.

Esto no significa que toda respuesta Brotli malformada vaya a provocar la ejecución de código. El problema es que una clase concreta de entrada malformada puede llegar a un comportamiento vulnerable en la gestión de memoria.

Dos rutas pueden llevar datos Brotli no confiables al decodificador

Hay al menos dos rutas importantes que conviene entender.

Un servicio recibe una respuesta HTTP comprimida

Piensa en un servicio de backend que obtiene datos de una API de terceros con el fetch() integrado de Node.js. El servidor remoto puede devolver una respuesta comprimida con Brotli. Cuando el cliente procesa esa respuesta, la operación de decodificación puede llegar a la implementación de Brotli incluida en Node.js. Si un atacante puede controlar los datos comprimidos que se devuelven a la aplicación, el decodificador se convierte en una posible superficie de ataque.

Esto no significa que cualquier uso de fetch() sea automáticamente explotable. La aplicación tiene que recibir una entrada comprimida pertinente, y tiene que alcanzarse la ruta de decodificación vulnerable. Sí muestra por qué una solicitud HTTP saliente puede ser relevante para la seguridad. Los desarrolladores suelen centrarse en proteger las solicitudes entrantes porque es ahí donde los usuarios externos interactúan con sus aplicaciones, pero las respuestas de servicios externos también son datos que cruzan un límite de confianza.

Un servicio descomprime el cuerpo de una solicitud entrante

La segunda ruta tiene que ver con el procesamiento del cuerpo de las solicitudes. Las aplicaciones creadas con Express pueden configurar middleware para analizar cuerpos de solicitud entrantes en JSON, en texto o sin procesar, y algunas configuraciones del analizador pueden descomprimir cuerpos codificados con Brotli antes de pasar su contenido al código de la aplicación. En esa situación, un cliente que envíe un cuerpo de solicitud comprimido y manipulado podría llegar al mismo decodificador vulnerable.

Un servidor HTTP básico de Node.js no descomprime automáticamente cada cuerpo de solicitud Brotli por el mero hecho de recibirlo. El procesamiento correspondiente tiene que habilitarse mediante middleware o código de la aplicación. Por eso, revisar la ruta real de procesamiento de solicitudes importa más que suponer que todas las aplicaciones de Express o de Node.js tienen la misma exposición.

Imperva demostró la ejecución de código en una compilación probada

El 22 de octubre, Imperva Threat Research publicó un análisis de Ron Masas titulado Node2Shell: From Brotli Data to Remote Code Execution. Sus investigadores probaron datos Brotli manipulados contra aplicaciones que ejecutaban la imagen oficial de Node.js 24.22.0 para Linux arm64. Informaron de una ejecución de código exitosa en dos escenarios de aplicación: un servicio que consume una respuesta HTTP comprimida mediante el fetch() integrado y aplicaciones que procesan cuerpos de solicitud entrantes comprimidos con Brotli con determinadas configuraciones de Express 5 y body-parser 2.

Las pruebas usaron un archivo marcador para demostrar que el código suministrado con los datos comprimidos maliciosos se había ejecutado dentro del proceso de la aplicación. Un dato importante: según Imperva, Node.js 24.22.1 rechazó esas mismas entradas sin que se creara el archivo marcador.

Los investigadores también señalaron limitaciones significativas. Su prueba de concepto no funcionó en todos los intentos, y no probaron todas las compilaciones de Node.js ni todas las configuraciones de aplicación. Estos resultados respaldan una conclusión concreta: se demostró la ejecución remota de código en el entorno probado con una compilación oficial vulnerable de Node.js. No establecen que la ejecución de código sea fiable en todos los entornos vulnerables, ni que los atacantes ya hayan comprometido aplicaciones en producción.

Una prueba de concepto que funciona y una explotación confirmada en entornos reales son formas distintas de evidencia. Según las fuentes revisadas para este artículo el 23 de octubre de 2026, no se ha establecido una explotación activa confirmada en ataques reales.

Express es una ruta hacia el decodificador, no la causa

Usar Express no hace, por sí solo, que una aplicación sea vulnerable. Las aplicaciones de Express pueden tener configuraciones de procesamiento de solicitudes muy distintas. Algunos endpoints analizan cuerpos comprimidos, mientras que otros pueden no invocar nunca la descompresión Brotli.

Imperva probó determinadas configuraciones con Express 5 y body-parser 2, y sus hallazgos demuestran que estos componentes pueden abrir una ruta hacia el decodificador afectado de Node.js. Express no era el origen subyacente del defecto de seguridad de memoria, y esa distinción determina la corrección adecuada. Cambiar la configuración de un middleware puede ayudar a reducir la exposición a determinadas entradas, pero no repara el decodificador vulnerable dentro de un entorno de ejecución de Node.js más antiguo.

La corrección principal es actualizar Node.js.

Aun así, los equipos deben revisar el middleware y la gestión del cuerpo de las solicitudes, porque esos componentes ayudan a determinar por dónde entran datos comprimidos no confiables en la aplicación.

Un firewall puede no cubrir la ruta saliente

Un firewall de aplicaciones web (WAF) puede inspeccionar y, en ocasiones, bloquear el tráfico HTTP entrante malicioso. Eso puede ofrecer una protección útil frente a ciertas rutas de ataque, sobre todo cuando la operación vulnerable implica cuerpos de solicitud que entran en un servicio público.

Vuelve al ejemplo anterior de una aplicación de Node.js que hace una solicitud saliente. Un firewall de entrada que protege los endpoints públicos de la aplicación no inspecciona necesariamente la respuesta comprimida que devuelve una API externa, así que el decodificador puede seguir recibiendo datos no confiables por esa otra ruta. Imperva informa de que ha desplegado reglas de WAF para los intentos de explotación que reprodujo, y a la vez recomienda a sus clientes que actualicen sus entornos de ejecución de Node.js.

Estos controles cumplen funciones distintas. Una regla de firewall puede reducir la exposición a tráfico malicioso conocido, mientras que una actualización de seguridad del entorno de ejecución corrige la vulnerabilidad subyacente. Limitar temporalmente el tráfico Brotli no confiable en las rutas afectadas, como sugiere Imperva, o filtrar otro tráfico puede ser útil mientras se despliegan las actualizaciones, siempre que los equipos entiendan el efecto sobre el comportamiento normal de la aplicación. Estas medidas no deben tratarse como un sustituto permanente de la aplicación de parches.

Comprueba la versión en ejecución, las rutas de datos y los artefactos desplegados

La prioridad inmediata es establecer qué versiones del entorno de ejecución de Node.js están realmente desplegadas.

Comprueba la versión de Node.js en ejecución

En un host o un entorno de desarrollo:

node --version

En un contenedor Docker en ejecución:

docker exec <container-name> node --version

En una imagen de contenedor disponible localmente:

docker run --rm --entrypoint node <image-name> --version

El último comando supone que la imagen puede ejecutarse con ese punto de entrada y que el ejecutable de Node.js está disponible en la ruta de búsqueda de ejecutables del contenedor. Estas comprobaciones identifican la versión del ejecutable de Node.js que se invoca. Por sí solas, no demuestran que toda la aplicación sea segura.

Revisa dónde se procesan datos comprimidos

Los equipos deben identificar las aplicaciones que descomprimen datos externos, en particular mediante:

• las API Brotli de Node.js en node:zlib
• llamadas al fetch() integrado que consumen respuestas comprimidas
• middleware de cuerpo de solicitud configurado para descomprimir los cuerpos entrantes
• otros paquetes o componentes que, en última instancia, usan el decodificador incluido

Esta revisión ayuda a priorizar la investigación de la exposición. No debe retrasar la instalación de las actualizaciones de seguridad disponibles.

Inspecciona los artefactos desplegados, no solo los archivos fuente

Un repositorio puede especificar una versión reciente de Node.js mientras una versión más antigua sigue dentro de una imagen de contenedor desplegada. Del mismo modo, puede que un pipeline de compilación se haya actualizado sin reconstruir todas las imágenes de aplicación derivadas de una imagen base más antigua. En los sistemas en contenedores, el proceso de corrección debe incluir reconstruir las imágenes afectadas, desplegarlas y verificar la versión de Node.js dentro de los contenedores en ejecución.

En los entornos de ejecución gestionados y los servicios serverless, los equipos deben confirmar la versión del entorno de ejecución y el estado de los parches que indica su proveedor, en lugar de suponer que todos los entornos ya se han actualizado. Si una aplicación todavía ejecuta una versión de Node.js sin soporte, la corrección adecuada puede requerir pasar a una línea de versiones con soporte.

Prueba la aplicación después de actualizar

Una actualización de seguridad del entorno de ejecución puede afectar al comportamiento de la aplicación, sobre todo cuando cambian el procesamiento de red, las dependencias o los componentes nativos. Los equipos deben ejecutar sus pruebas de regresión habituales, verificar las integraciones HTTP esenciales y confirmar que el análisis de solicitudes y la descompresión siguen comportándose correctamente con entradas válidas. La aplicación de parches de seguridad debe ser rápida, pero el despliegue debe seguir siendo controlado y verificable.

La misma versión corrigió otras nueve vulnerabilidades

El problema de Brotli es el foco principal de este artículo, pero la versión de octubre abordó un conjunto más amplio de problemas de seguridad. Los demás hallazgos son relevantes porque afectan a supuestos que los desarrolladores y los equipos de plataforma pueden hacer sobre el comportamiento del entorno de ejecución.

Las demás áreas de seguridad corregidas en la misma versión

Área de seguridad	Hallazgos relevantes	Por qué debe importar a los equipos
Validación de certificados TLS	CVE-2026-105483, CVE-2026-106069, CVE-2026-106072	Ciertas representaciones no estándar de direcciones IP pueden provocar una coincidencia incorrecta de la identidad del certificado en determinadas condiciones.
Resolución DNS	CVE-2026-105482	Los nombres de host que contienen caracteres NUL (bytes cero) pueden truncarse durante la resolución, lo que crea diferencias entre los nombres validados y los resueltos.
Aleatoriedad criptográfica	CVE-2026-106074	Ciertas instantáneas de arranque y aplicaciones ejecutables únicas (programas empaquetados autónomos) pueden conservar cachés de entropía, que son valores aleatorios almacenados, y hacer que valores que deberían ser únicos o impredecibles se repitan entre procesos.
Reutilización de conexiones HTTP	CVE-2026-105481	En determinadas condiciones de temporización, un cliente HTTP puede asociar una respuesta no solicitada con una solicitud posterior.
Procesamiento de ZIP	CVE-2026-106070	En Node.js 26.x, un fallo de validación de ZIP puede hacer que se devuelvan bytes inesperados controlados por el atacante.
Permission Model del sistema de archivos	CVE-2026-106071, CVE-2026-106073	Determinados comportamientos de la coincidencia de rutas y de las API del sistema de archivos pueden eludir las restricciones de permisos previstas.

Estas vulnerabilidades no tienen todas los mismos requisitos previos, gravedad, consecuencias ni líneas de versiones afectadas. Según el aviso, CVE-2026-105483 afecta a 26.x y 24.x; el problema de ZIP, CVE-2026-106070, y el del comodín del sistema de archivos, CVE-2026-106071, afectan solo a 26.x, y los demás afectan a las tres líneas. Por ejemplo, el problema de aleatoriedad requiere un comportamiento concreto relacionado con las instantáneas. No es evidencia de que cada llamada a crypto.randomUUID() produzca valores predecibles. Del mismo modo, los problemas de TLS implican representaciones específicas de nombres de host y condiciones concretas de validación de certificados, y no deben describirse como un fallo general del cifrado TLS.

El aviso oficial de Node.js detalla las líneas de versiones afectadas y las condiciones técnicas de cada vulnerabilidad. Los equipos de ingeniería deben consultar esos detalles al investigar su propia exposición.

La seguridad de las aplicaciones se extiende al entorno de ejecución

Un desarrollador puede escribir código de aplicación cuidadoso, validar las entradas y mantener actualizadas las dependencias de la aplicación. Esas prácticas siguen siendo necesarias, pero las aplicaciones también dependen del comportamiento del entorno de ejecución sobre el que funcionan. Un cliente HTTP puede descomprimir datos. Una biblioteca TLS puede interpretar un nombre de host. Un resolutor (resolver) DNS puede transformar un nombre. Una API criptográfica puede depender de un estado creado durante el arranque de la aplicación. Cada una de esas operaciones puede afectar a una decisión de seguridad.

Las vulnerabilidades de Node.js de octubre ilustran varias formas en que el comportamiento de bajo nivel puede socavar supuestos hechos en capas superiores de una aplicación. El problema de Brotli ofrece un ejemplo especialmente concreto, porque los investigadores demostraron una ruta desde datos HTTP comprimidos corrientes hasta la ejecución de código en un entorno de Node.js probado. Eso no hace que todas las aplicaciones de Node.js sean explotables. Sí demuestra por qué los equipos deben entender qué capacidades del entorno de ejecución usan realmente sus aplicaciones.

Las recientes vulnerabilidades PHP2Shell analizadas por TechiesJournal ofrecen una lección relacionada desde otro entorno de ejecución, aunque los mecanismos técnicos subyacentes y las condiciones de exposición son distintos. En ambos ecosistemas, un código de aplicación seguro no puede compensar por sí solo un fallo de seguridad de memoria sin parchear en el entorno de ejecución que lo ejecuta.

Los pasos inmediatos: aplicar el parche, mapear y verificar

La acción inmediata es sencilla: identifica los despliegues de Node.js afectados y llévalos a las versiones corregidas que correspondan, que son 22.23.4, 24.22.1 o 26.12.1, o a versiones con soporte más recientes que contengan las correcciones. Al mismo tiempo, los desarrolladores y los equipos de seguridad deben identificar dónde llegan datos comprimidos no confiables a las funciones de descompresión del entorno de ejecución, incluso a través de respuestas HTTP salientes y de middleware de cuerpo de solicitud configurado. Los equipos de infraestructura deben verificar el entorno de ejecución realmente desplegado en contenedores, hosts y entornos gestionados, en lugar de basarse solo en las versiones previstas en la configuración del control de código fuente.

Si hay indicios de comportamiento sospechoso, investígalos con los registros (logs) de la aplicación, la información del entorno de ejecución y la telemetría de seguridad pertinente. Una caída del proceso o un error de descompresión no son, por sí solos, prueba de una vulneración. No hay por qué suponer que todas las aplicaciones de Node.js han sido atacadas. Tampoco hay ninguna razón sólida para retrasar una actualización de seguridad disponible del entorno de ejecución solo porque no hayan surgido pruebas públicas de una explotación generalizada.

La lección principal va más allá de Brotli.

Las aplicaciones heredan límites de seguridad de sus entornos de ejecución. Saber dónde cruzan esos límites los datos no confiables forma parte de entender la superficie de ataque real de la aplicación.

Para profundizar

Investigación revisada el 23 de octubre de 2026. La actividad de amenazas, la disponibilidad de parches y las recomendaciones de los proveedores pueden cambiar con rapidez, así que consulta las fuentes primarias antes de actuar.

Fuentes de proveedores, investigadores y organismos públicos

• Node.js, October 21, 2026 Security Releases, proyecto Node.js, 21 de octubre de 2026, el aviso principal que cubre las diez CVE, las líneas de versiones afectadas, las descripciones técnicas y las correcciones publicadas.
• Node2Shell: From Brotli Data to Remote Code Execution, Imperva Threat Research, 22 de octubre de 2026, detalles de los experimentos de ejecución de código comunicados, la compilación de Node.js probada, las rutas de exposición por solicitudes y respuestas, la comparación con la versión parcheada y las limitaciones.
• Detect and Report Invalid Stream Earlier, commit del código fuente original (upstream) de Google Brotli, evidencia a nivel de código de los cambios en la gestión de errores del decodificador.
• Node.js Multiple Vulnerabilities, Hong Kong Computer Emergency Response Team Coordination Centre, 22 de octubre de 2026, un boletín de seguridad adicional que resume el impacto y las versiones de seguridad recomendadas.

Este artículo distingue entre avisos de proveedores, hallazgos experimentales comunicados y recomendaciones prácticas de ingeniería. La exposición propia de cada despliegue y la actividad de amenazas posterior deben reevaluarse antes de actuar.

Lecturas relacionadas en TechiesJournal

• Vulnerabilidades críticas de PHP: a quién afectan, qué podría ocurrir y cómo parchear con seguridad, TechiesJournal, octubre de 2026, la vulnerabilidad relacionada del entorno de ejecución de PHP y cómo aplicar el parche con seguridad.
• Node.js, Docker y Go: tres cambios silenciosos que pueden romper tu pipeline (en inglés), TechiesJournal, octubre de 2026, sobre otros cambios del entorno de ejecución de Node.js y de los contenedores que afectan a los pipelines de entrega.