Seguridad de Node.js, octubre de 2026: RCE en Brotli y fallos de TLS

El 21 de octubre de 2026 el proyecto Node.js publicó las versiones 22.23.4, 24.22.1 y 26.12.1. Corrigen diez vulnerabilidades, cuatro de ellas de gravedad alta. La más grave, CVE-2026-111497, es una escritura fuera de límites en el decodificador Brotli de Node: unos datos comprimidos malformados pueden corromper la memoria, y la empresa de alojamiento Vercel informa de que unos investigadores la utilizaron para leer la memoria del proceso y ejecutar comandos con los permisos del proceso de Node.js. Otros dos fallos de gravedad alta permiten que un certificado TLS supere la comprobación del nombre de host cuando no debería. Node.js 20 y 25 han llegado al final de su vida útil y no recibirán corrección.

Qué versiones están corregidas

Cuáles son los diez fallos

Las versiones también actualizan componentes incluidos: c-ares, Undici, la lista de CA de confianza (con la eliminación de la CA intermedia comprometida de eMudhra), OpenSSL en 24 y 22, y SQLite en 22.

Quién está expuesto al fallo de Brotli

Node.js no decodifica Brotli por sí solo. Está expuesto cuando su código, o una biblioteca que utiliza, descomprime datos Brotli controlados por otra persona. Ocurre con más frecuencia de lo que parece:

• El fetch() integrado decodifica automáticamente las respuestas con Content-Encoding: br. Un servicio que obtiene URL elegidas por usuarios, webhooks o API de terceros puede recibir una respuesta maliciosa.
• axios, got y node-fetch también decodifican las respuestas comprimidas de forma predeterminada.
• Express 5 (body-parser 2) decodifica de forma predeterminada los cuerpos de petición Brotli, de modo que una API puede recibir los datos directamente de un atacante.
• Cualquier llamada a zlib.brotliDecompress, zlib.createBrotliDecompress o DecompressionStream sobre archivos subidos o datos de terceros.

Parchee primero donde estos casos se encuentran con internet: las API públicas que aceptan cuerpos comprimidos, los servicios que obtienen URL proporcionadas por usuarios y todo lo que descomprime archivos subidos.

Los fallos de TLS importan sobre todo cuando un atacante puede obtener, de una CA en la que confía su cliente, un certificado que contenga un nombre DNS con forma de IP, y el fallo de DNS cuando su código pasa datos externos a dns.resolve. Según el commit de la corrección, los problemas de TLS no son fáciles de explotar, pero la misma actualización los cierra.

Paso 1: localice cada entorno de ejecución de Node.js

En Linux, liste cada binario node con su versión:

sudo find / -xdev -type f -name node -perm -u+x 2>/dev/null | while read -r n; do echo "$n: $("$n" --version 2>/dev/null)"; done

Compruebe qué entorno de ejecución usan los procesos en marcha:

for p in $(pgrep -x node); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

En Docker, compruebe cada contenedor en ejecución:

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" node --version 2>/dev/null)"; done

Revise también los gestores de versiones (nvm, fnm, Volta, asdf), los ejecutores de CI, las imágenes de compilación, las aplicaciones Electron y las funciones serverless, donde la versión del entorno de ejecución se fija en la configuración del proyecto.

Paso 2: actualice

Ubuntu y Debian con los paquetes de NodeSource:

sudo apt update && sudo apt install --only-upgrade nodejs && node --version

Con nvm:

nvm install 24.22.1 && nvm alias default 24.22.1

Contenedores: cambie la imagen base a una versión fija, por ejemplo node:24.22.1-alpine o node:22.23.4-bookworm-slim, reconstruya y vuelva a desplegar. Actualizar el host no cambia lo que se ejecuta dentro de un contenedor.

Plataformas serverless y de alojamiento: en Vercel, los proyectos en 22.x y 24.x los parchea Vercel, y Vercel añadió reglas de firewall contra el ataque entrante; los proyectos que siguen en 20.x deben pasar a 22.x o 24.x y volver a desplegarse. En otras plataformas, consulte el aviso del proveedor y vuelva a desplegar cuando el entorno de ejecución parcheado esté disponible.

Los paquetes de las distribuciones, como el propio paquete nodejs de Ubuntu, suelen ir con retraso. Si node --version no muestra 22.23.4, 24.22.1 ni 26.12.1 (ni una compilación de la distribución que mencione estos CVE), utilice las versiones oficiales.

Paso 3: reinicie y verifique

Un proceso en ejecución conserva el entorno de ejecución antiguo hasta que se reinicia. Tras actualizar un paquete en Linux, este comando lista los procesos node que aún ejecutan el binario sustituido:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'node.*(deleted)'

Reinicie esos servicios (por ejemplo con systemctl restart, pm2 reload all o un nuevo despliegue) y vuelva a ejecutar los comandos del paso 1.

Si no puede actualizar hoy

Ninguna de estas medidas sustituye a la actualización, pero reducen el riesgo durante unos días:

• Rechace los cuerpos de petición Brotli antes de que lleguen a la aplicación, por ejemplo en NGINX con if ($http_content_encoding ~* br) { return 415; }, o en un middleware que se ejecute antes de los analizadores de cuerpo.
• Desactive la descompresión automática en las peticiones a servidores no fiables: decompress: false en axios y got, compress: false en node-fetch, o request() de undici, que no descomprime. El fetch() integrado no se puede desactivar.
• Ejecute las peticiones a URL proporcionadas por usuarios en un proceso aparte con los menores permisos posibles.
• Antes de pasar datos externos a dns.resolve, rechace los nombres que contengan un carácter NUL.

Si no está seguro de cuáles de sus servicios decodifican datos no fiables, o necesita ayuda para actualizar un sistema en producción sin interrupciones, nuestros equipos de software seguro y de seguridad gestionada pueden ayudarle.