Node2Shell: la falla de Node.js con Brotli, cómo saber si te afecta y qué actualizar

Qué pasó, en corto

• La falla: CVE-2026-111497, una escritura fuera de límites en el decodificador Brotli que viene incluido en Node.js. Node.js la califica como alta y advierte que permite ejecución remota de código.
• El arreglo: salió el 21 de octubre de 2026 en las versiones 22.23.4, 24.22.1 y 26.12.1. Como el decodificador está dentro de Node.js, actualizar las dependencias de tu proyecto no basta: hay que actualizar Node.js.
• Node.js 20 se queda sin parche: esa rama dejó de tener soporte en abril de 2026 y no recibe esta corrección. Lo mismo pasa con la 18 y las ramas impares.
• Por ahora sin ataques conocidos: no se reporta explotación real, pero investigadores ya lograron la ejecución de código en laboratorio.

Versiones corregidas

La misma actualización trae el arreglo de otras tres fallas altas de esa semana, en la resolución de DNS y en la verificación de certificados TLS. Otra razón para no dejarla para después.

¿Mi aplicación está expuesta?

La falla se dispara cuando Node.js descomprime datos Brotli preparados por un atacante. La pregunta clave es si tu aplicación descomprime Brotli que viene de alguien que no controlas:

• Tu servidor acepta peticiones comprimidas. Si usas Express 5 o body-parser 2, el middleware descomprime solo los cuerpos que llegan con Content-Encoding: br. Cualquiera en internet puede mandar uno.
• Tu app consume respuestas de terceros. El fetch() integrado de Node.js acepta y descomprime respuestas Brotli. Si llamas a URLs que pone el usuario (vistas previas de enlaces, webhooks, scrapers) o a servidores que no controlas, un servidor malicioso podría mandarte una respuesta preparada.
• Tu código usa zlib directamente. zlib.brotliDecompress o createBrotliDecompress sobre archivos que suben los usuarios o datos de terceros.
• Riesgo bajo: un servidor que no descomprime cuerpos de petición y solo hace fetch() a tus propios servicios o a APIs de confianza. Igual hay que actualizar, pero no es una urgencia de hoy.

Cómo revisar en 5 minutos, según dónde corre

• Servidores (EC2, Lightsail, VPS): corre node -v y compara con la tabla. Si usas nvm o varias versiones, revisa la que levanta el servicio, no solo la de tu usuario.
• Contenedores (ECS, EKS, Docker): mira la imagen base (por ejemplo node:22-alpine) y la versión real dentro del contenedor. Una imagen construida antes del 21 de octubre sigue vulnerable aunque diga 22: hay que reconstruirla y volver a desplegar.
• AWS Lambda: con los runtimes administrados nodejs22.x y nodejs24.x, AWS aplica los parches de seguridad por ti, salvo que hayas fijado la versión del runtime. El nodejs20.x quedó en fin de soporte el 30 de abril de 2026: las funciones siguen corriendo, pero ya no reciben parches de Node.js. Si usas Lambda con imagen de contenedor, la reconstruyes tú.
• Vercel: en Settings, Build and Deployment, Node.js Version. Vercel solo ofrece 22.x y 24.x y aplica los parches de esas ramas por su cuenta.

Qué hacer, en orden

1. 1. Actualizar Node.js a 22.23.4, 24.22.1 o 26.12.1, o una posterior, y reiniciar el servicio. Es la única solución completa.
2. 2. Sacar todo lo que siga en Node.js 20. Funciones Lambda en nodejs20.x, imágenes node:20 y servidores viejos: pásalos a 22 o 24. Es la parte que más se olvida.
3. 3. Si no puedes actualizar hoy, rechaza los cuerpos de petición con Content-Encoding: br en las rutas que no los necesitan, en el balanceador, en AWS WAF o en tu código. Baja el riesgo, pero el decodificador sigue vulnerable hasta actualizar.
4. 4. Vigilar caídas raras. Si un proceso de Node.js se reinicia mientras descomprime datos, revísalo: no prueba un ataque, pero es la señal a mirar.

Preguntas frecuentes