Si la aplicación, la web, la tienda online o la API de tu empresa se desarrolló con Node.js, incluidas las webs hechas con Next.js y los backends con Express o NestJS, pide hoy a tu desarrollador que actualice Node.js a la versión 22.23.4, 24.22.1 o 26.12.1 y que después reconstruya y reinicie el servidor. El proyecto Node.js publicó estas versiones el 21 de octubre de 2026 para cerrar una vulnerabilidad conocida como Node2Shell (CVE-2026-111497), con una puntuación de 9.2 sobre 10, que permite a un atacante sin ninguna contraseña ejecutar código en tu servidor enviándole datos comprimidos especialmente manipulados. La Autoridad Nacional de Ciberseguridad de Arabia Saudí (NCA) ha emitido una alerta de nivel «muy alto», y el 27 de octubre la agencia estadounidense de ciberseguridad CISA confirmó que la vulnerabilidad se está explotando en ataques reales.

¿Qué ha pasado exactamente?

La vulnerabilidad está en Brotli, un formato de compresión que los servidores web y los navegadores usan para reducir los datos que intercambian, y Node.js incluye su propia copia del descompresor Brotli de Google. Según el aviso de seguridad de Node.js, unos datos comprimidos malformados hacen que el descompresor escriba más allá del final de un búfer interno, lo que puede bloquear la aplicación, filtrar el contenido de su memoria o permitir que un atacante ejecute código. El aviso atribuye el reporte de la vulnerabilidad al equipo Codex Security de OpenAI, y la misma versión corrigió 10 vulnerabilidades en total, 4 de ellas de gravedad alta.

A partir de ahí todo fue muy rápido. El 22 de octubre, un día después de la corrección, el Red Team de Imperva ejecutó código en la imagen oficial de Node.js 24.22.0 por dos vías cotidianas: la función integrada fetch() y los cuerpos de las peticiones que procesa Express 5. El 26 de octubre, ELLIO registró tráfico de explotación real con código de ataque público. El 27 de octubre, CISA añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas activamente.

El fallo en sí es antiguo. Según el registro CVE, afecta a las versiones 1.0.3 a 1.2.0 de Brotli, y OpenAI afirma que la causa de fondo se corrigió en el código fuente de Brotli en febrero de 2026 sin que nadie supiera que era un fallo de seguridad y sin una nueva versión, hasta que salió Brotli 1.2.1 el 21 de octubre. Si te suena, es normal: la semana pasada hablamos de PHP2Shell, la vulnerabilidad que abrió servidores PHP y WordPress. Node2Shell es el mismo tipo de riesgo para las aplicaciones hechas con JavaScript.

¿Está afectada mi aplicación?

Node.js mueve la parte de servidor de una gran parte de las webs modernas, los backends de aplicaciones móviles, los paneles de control y las API. Si tu sistema lo desarrolló en los últimos años una agencia o un programador freelance, es bastante probable que funcione con Node.js sin que lo sepas. Las ramas afectadas son 22.x, 24.x y 26.x anteriores a las versiones corregidas, además de las ramas sin soporte 20.x, 23.x y 25.x, que según el proyecto Node.js siempre están afectadas y no recibirán corrección.

Tener Node.js no basta para estar expuesto: algo tiene que entregar los datos del atacante al descompresor. Los investigadores señalan tres vías habituales:

  • Peticiones comprimidas entrantes. Los analizadores del cuerpo de las peticiones de Express 5, body-parser 2 y Koa descomprimen automáticamente los cuerpos en formato Brotli, antes incluso de que se ejecute tu propio código.
  • Contenido que tu servidor descarga. Si tu aplicación abre enlaces externos, como vistas previas de enlaces, webhooks, rastreadores o agentes de IA que leen páginas web, un sitio hostil puede responder con datos comprimidos envenenados. La función integrada fetch() de Node, axios y las peticiones del lado del servidor en frameworks como Next.js los descomprimen automáticamente.
  • Archivos que suben los usuarios. Cualquier código que descomprima datos Brotli enviados por un cliente o un visitante.

El riesgo va más allá de Node.js. La alerta de la NCA menciona también Python, Bun y Envoy, y Microsoft publicó el 25 de octubre correcciones para .NET 8, 9, 10 y 11, Visual Studio 2019, 2022 y 2026, y PowerShell 7.4 a 7.6, y calificó la vulnerabilidad como crítica para .NET con la valoración «Exploitation More Likely». Microsoft aclara que la descompresión Brotli no está activada por defecto en .NET, así que solo están expuestas las aplicaciones que la activaron.

Si tu web está alojada en Vercel, la empresa dice en su aviso que desplegó reglas de firewall que bloquean la vía de ataque entrante para todos los proyectos el mismo día en que Node.js publicó la corrección, y que todos los despliegues nuevos usan un Node.js corregido desde el 28 de octubre. Los proyectos existentes necesitan un nuevo despliegue, y los que siguen en Node.js 20 deben pasar a 22 o 24.

Qué hacer hoy: cinco pasos

  1. Haz una pregunta por escrito. ¿Qué versión de Node.js funciona en nuestros servidores y dentro de nuestras imágenes Docker? Pide a tu desarrollador que compruebe el número de versión de Node.js con el comando node -v. No te fíes del número de versión de Brotli: ELLIO comprobó que muestra 1.2.0 tanto en las versiones corregidas como en las vulnerables.
  2. Actualiza a una versión corregida. 22.23.4, 24.22.1 o 26.12.1. Si estás en 20.x, 23.x o 25.x, pasa a una rama con soporte como la 22 o la 24, y haz pruebas antes de publicar.
  3. Reconstruye y reinicia. Un proceso en ejecución conserva el código antiguo. Reconstruye las imágenes de contenedores sobre una imagen base corregida, porque un Dockerfile fijado en 24.22.0 seguirá distribuyendo la versión vulnerable hasta que alguien cambie esa línea. Revisa también los servidores de pruebas, los pipelines de compilación y las funciones serverless.
  4. Actualiza las demás copias. Los paquetes de Python Brotli y brotlicffi (versiones 1.2.1 y 1.2.1.0), Bun, Envoy, la biblioteca Brotli de tu distribución Linux y .NET mediante la actualización de Microsoft del 25 de octubre.
  5. Revisa los registros y los archivos de volcado. Busca peticiones comprimidas con Brotli inusualmente grandes y caídas repetidas de los procesos. ELLIO advierte de que la mayoría de los ataques fallidos tumban el proceso y de que un archivo de volcado puede guardar las cookies de sesión y las claves de los visitantes, así que limita quién puede leer esos archivos (core dumps) y cuánto tiempo los conservas.

Si no puedes actualizar hoy

Como medida temporal, bloquea en tu servidor frontal o en tu firewall las peticiones entrantes que lleven la cabecera Content-Encoding: br, si tu aplicación no las necesita. Vercel e Imperva han añadido reglas de firewall para esta vulnerabilidad, pero la propia Vercel insiste en que un firewall no cubre las respuestas que tu servidor descarga de otros sitios: solo la actualización de Node.js cierra esa vía. Considera cualquier capa de protección como tiempo extra, no como sustituto de la actualización.

La visión de Origami

Dos vulnerabilidades críticas en los cimientos de la web en un solo mes, PHP2Shell y después Node2Shell, cuentan una historia clara: el código que escribió tu equipo puede estar bien mientras el entorno de ejecución que hay debajo está abierto. La corrección de Node2Shell pasó unos ocho meses en el código fuente de Brotli antes de que alguien entendiera que era un problema de seguridad, y una vez publicados los detalles, los investigadores necesitaron un día para ejecutar código en una versión oficial. Lo que vemos en muchas empresas es una aplicación entregada hace años, sin nadie responsable de sus actualizaciones y sin una lista de dónde funciona realmente Node.js. Si es tu caso, empieza esa lista hoy. En Origami desarrollamos aplicaciones web y sistemas, muchos de ellos con Node.js y Next.js, y vigilamos las actualizaciones de su entorno desde el primer día. Si quieres que revisemos tu aplicación o que actualicemos Node.js sin interrupciones, contacta con nosotros.

Fuentes