Node2Shell: la vulnerabilidad crítica de Node.js (CVE-2026-111497)

1. Introducción

Solo unos días después de PHP2Shell, el mundo del desarrollo web ha vuelto a recibir un aviso de seguridad urgente: el 21 de octubre de 2026 el proyecto Node.js publicó actualizaciones de seguridad para todas sus ramas activas, corrigiendo diez vulnerabilidades, cuatro de ellas de severidad alta.

La más importante tiene nombre propio, Node2Shell (CVE-2026-111497), y permite ejecución remota de código a través del descompresor Brotli que incluye Node.js. Node.js mueve APIs, microservicios, aplicaciones web, herramientas de compilación y buena parte del software de empresa moderno, por lo que conviene saber qué ha pasado y qué hay que hacer.

En esta entrada explicamos de qué trata, a qué afecta y cómo corregirla.

Nota: la información corresponde a principios de noviembre de 2026 y puede cambiar. Verifica siempre el aviso oficial de Node.js antes de actuar.

Índice

1. Introducción
2. Qué se ha publicado: el paquete de seguridad de octubre
3. La vulnerabilidad principal: Node2Shell (CVE-2026-111497)
4. Quién está expuesto
5. Versiones afectadas y corregidas
6. Cómo corregirlo
7. Si no se puede actualizar ya: mitigaciones temporales
8. Las otras vulnerabilidades del paquete
9. Cómo comprobar si somos vulnerables o hemos sido atacados
10. Buenas prácticas para el futuro
11. Conclusión
12. Fuentes

2. Qué se ha publicado: el paquete de seguridad de octubre

El 21 de octubre de 2026 Node.js lanzó versiones de seguridad coordinadas para las tres ramas con soporte (22.x, 24.x y 26.x):

• Node.js 22.23.4
• Node.js 24.22.1
• Node.js 26.12.1

Estas versiones corrigen diez CVE y actualizan también dependencias incluidas en Node.js, como OpenSSL, undici, c-ares, SQLite (en 22.x) y el paquete de certificados de CA.

Cronología relevante:

• 21 de octubre: publicación de las versiones corregidas.
• 22 de octubre: varios investigadores (Imperva y Aikido, entre otros) demostraron ejecución de código contra una imagen oficial sin parchear de Node.js 24.22.0, y confirmaron que la 24.22.1 rechaza la misma entrada. Hasta esa fecha no se había reportado explotación en el mundo real.
• 27 de octubre: la agencia estadounidense CISA añadió el CVE-2026-111497 a su catálogo de vulnerabilidades explotadas conocidas (KEV). Esto confirma explotación del componente Brotli, sin indicar qué despliegues concretos de Node.js fueron atacados.

3. La vulnerabilidad principal: Node2Shell (CVE-2026-111497)

Qué es: una escritura fuera de límites (out-of-bounds write) en el decodificador Brotli que Node.js incluye en su módulo node:zlib. Su puntuación es CVSS 9.2 (crítica), aunque el proyecto Node.js la califica como severidad alta.

Qué es Brotli: un formato de compresión muy usado en la web, por ejemplo en la cabecera HTTP Content-Encoding: br.

Cuál es el fallo: un flujo Brotli puede indicar un cambio de tipo de bloque durante la descompresión. Cuando ese cambio es inválido según la propia estructura del flujo, el decodificador vulnerable lo trataba como «necesito más datos» en lugar de como un error de formato definitivo. Como resultado, el decodificador seguía añadiendo bytes a un búfer interno de ocho bytes y escribía más allá de su final.

Qué puede provocar: corrupción de la memoria del proceso, que puede acabar en una caída del servicio, divulgación de memoria o ejecución remota de código (RCE). No requiere autenticación.

Detalle importante: el fallo está en la librería Brotli de origen, no solo en Node.js. La corrección incorpora un arreglo del proyecto Brotli, que ahora devuelve un error de formato específico y rechaza el flujo malformado.

4. Quién está expuesto

No hace falta llamar a la API de Brotli directamente para estar expuesto. Los datos controlados por un atacante pueden llegar al decodificador por varias rutas:

• node:zlib: aplicaciones que pasan entrada no confiable a zlib.brotliDecompress() o zlib.createBrotliDecompress().
• fetch() integrado: descomprime automáticamente respuestas con Brotli. Un servidor malicioso o comprometido puede atacar a la aplicación cliente que lo consulta.
• Express 5 y body-parser 2: sus analizadores json, raw, text y urlencoded descomprimen por defecto los cuerpos de petición enviados con Content-Encoding: br, porque la opción inflate está activada. Cualquier cliente puede enviar ese tipo de petición.

Un servidor HTTP básico de Node.js sin esas capas no descomprime por sí solo los cuerpos entrantes; la descompresión HTTP queda en manos de la aplicación.

En resumen, el riesgo es mayor en:

• APIs con Express 5 expuestas a Internet.
• Aplicaciones que consumen servicios externos o de terceros con fetch().
• Proxies, agregadores, integraciones y webhooks que procesan contenido de orígenes no controlados.

Según telemetría de Akamai, el 61% de las redes que observa ejecutaban versiones afectadas.

5. Versiones afectadas y corregidas

Rama	Versiones afectadas	Versión corregida	Estado
Node.js 26.x	anteriores a 26.12.1	26.12.1	Soportada
Node.js 24.x	anteriores a 24.22.1	24.22.1	Soportada
Node.js 22.x	anteriores a 22.23.4	22.23.4	Soportada
Node.js 25.x, 23.x, 20.x y anteriores	todas	Sin corrección	Fin de vida

Las ramas descontinuadas no reciben parche. Node.js indica que las versiones fuera de soporte deben considerarse siempre afectadas cuando sale una versión de seguridad. Por ejemplo, Node.js 20 llegó a su fin de vida el 30 de abril de 2026.

Otros runtimes: Bun también incluye Brotli. Akamai recomienda comprobar su versión y actualizarla si es inferior a la 1.4.4. Las compilaciones de distribuciones Linux pueden incorporar parches propios, por lo que hay que revisar los avisos del proveedor.

6. Cómo corregirlo

El aviso de Node.js no ofrece una solución alternativa: actualizar es la única corrección completa.

Paso 1: identificar qué versiones usamos

node -v

Revisar también:

• Servidores y máquinas virtuales.
• Imágenes Docker (FROM node:...) y registros de contenedores.
• Pipelines de CI/CD y runners de compilación.
• Funciones serverless y runtimes gestionados (Lambda, Cloud Functions, etc.).
• Aplicaciones de escritorio basadas en Electron o que empaquetan su propio Node.js.

Paso 2: actualizar según el entorno

• Instalación directa o con gestor de versiones (nvm, fnm, Volta): instalar 22.23.4, 24.22.1 o 26.12.1 según la rama que usemos.
• Paquetes del sistema (apt, yum, dnf) o NodeSource: actualizar el paquete nodejs y comprobar que la versión resultante incluye el arreglo (o el parche retroportado del proveedor).
• Contenedores: actualizar la imagen base (por ejemplo node:24.22.1 o node:22.23.4-bookworm-slim), reconstruir y volver a desplegar. Si se fija una etiqueta concreta hay que actualizarla manualmente en cada versión futura.
• Plataformas gestionadas: esperar o solicitar la actualización del runtime al proveedor y revisar sus fechas de despliegue.

Paso 3: reiniciar y verificar

Reiniciar los procesos para que carguen el nuevo binario y verificar la versión en ejecución, no solo la instalada.

Paso 4: si estamos en una rama sin soporte

Migrar a una rama soportada (22, 24 o 26), idealmente la LTS activa. Hay que probar la compatibilidad de dependencias antes de pasar a producción.

7. Si no se puede actualizar ya: mitigaciones temporales

Estas medidas reducen la exposición pero no sustituyen al parche.

• Desactivar los cuerpos de petición comprimidos si la aplicación no los necesita: en body-parser, establecer inflate: false. Las peticiones con cuerpo comprimido se rechazarán con un error HTTP 415.
• Filtrar Content-Encoding: br en peticiones entrantes en el proxy inverso, balanceador o WAF, si no se usa de forma legítima.
• No pasar entrada no confiable a zlib.brotliDecompress() y similares.
• Limitar las llamadas salientes con fetch() a destinos de confianza, y evitar consumir contenido de orígenes no controlados desde servicios críticos.
• Segmentar la red: restringir quién puede acceder a los servicios Node.js y limitar sus conexiones salientes para reducir el impacto si son comprometidos.
• Ejecutar con privilegios mínimos, en contenedores sin root y con sistema de archivos de solo lectura cuando sea posible.
• Monitorizar reinicios inesperados del proceso, errores de memoria y procesos hijo anómalos.

8. Las otras vulnerabilidades del paquete

Además del fallo Brotli, el paquete corrige otros nueve problemas. Los más relevantes:

CVE	Severidad	Descripción	Ramas afectadas
CVE-2026-111497	Alta	Escritura fuera de límites en el decodificador Brotli (RCE)	26, 24, 22
CVE-2026-105482	Alta	dns.resolve*() trunca nombres con un carácter NUL, lo que puede eludir defensas contra SSRF	26, 24, 22
CVE-2026-105483	Alta	Elusión de verificación de nombre en TLS con IP escrita en dígitos de ancho completo	26, 24
CVE-2026-106069	Alta	Fallo relacionado con la verificación de identidad TLS	según aviso oficial
CVE-2026-106072	Media	Nombres DNS en certificados que autentican IPv4 no canónicas	26, 24, 22
CVE-2026-106073	Baja	Elusión del Permission Model mediante fs.realpathSync()	26, 24, 22
CVE-2026-106070	Baja	zlib.ZipFile devuelve bytes controlados por el atacante tras un error de validación	26
CVE-2026-106071	Baja	El Permission Model concede más acceso del previsto con rutas comodín	26

Los fallos de TLS y DNS afectan sobre todo a aplicaciones que se conectan a otros servicios (clientes HTTPS, integraciones, proxies), y se corrigen con las mismas versiones. En la tabla solo se muestran los más relevantes; consulta el aviso oficial para la lista completa y los detalles de cada ramas.

9. Cómo comprobar si somos vulnerables o hemos sido atacados

Inventario

• Buscar procesos node en ejecución y sus versiones en servidores, contenedores y runners.
• Revisar imágenes de contenedor y el SBOM (inventario de software) de las aplicaciones.
• Herramientas de gestión de la superficie de ataque y de vulnerabilidades pueden automatizarlo; algunos proveedores han publicado consultas para localizar activos afectados.

Indicios de explotación

• Caídas o reinicios repentinos de procesos Node.js tras recibir peticiones con Content-Encoding: br.
• Peticiones con cuerpos Brotli inusuales o malformados en los logs del proxy o del servidor.
• Procesos hijo inesperados (sh, bash, curl, wget) lanzados por el proceso Node.js.
• Conexiones salientes no habituales desde los servidores de aplicación.
• Ficheros nuevos o modificados, tareas programadas o claves SSH que no reconozcamos.

Si hay sospecha

1. Aislar el sistema de la red.
2. Conservar logs y evidencias.
3. Rotar credenciales, tokens y claves accesibles desde ese servidor.
4. Reconstruir desde una imagen limpia y actualizada en lugar de intentar limpiar el sistema.
5. Revisar posibles movimientos laterales.

En nuestro entorno, FortiAnalyzer permite correlacionar los logs del firewall con los de los servidores para localizar tráfico y conexiones salientes sospechosas.

10. Buenas prácticas para el futuro

• Inventario vivo de runtimes y dependencias, incluidos contenedores y pipelines.
• Plazos de parcheo definidos para vulnerabilidades críticas, medidos en horas o días.
• Control del ciclo de vida: planificar la migración antes del fin de soporte de cada rama.
• Imágenes base actualizadas automáticamente y reconstrucción periódica de contenedores.
• Suscripción a los avisos de Node.js (lista nodejs-sec), de la distribución y de los frameworks que usamos.
• Principio de mínimo privilegio, aislamiento por servicio y segmentación de red.
• Filtrado de tráfico saliente y WAF o proxy inverso con límites de tamaño y de codificaciones aceptadas.
• No procesar datos no confiables con funciones innecesarias: desactivar lo que no se use, como la descompresión de cuerpos de petición.
• Plan de respuesta a incidentes probado, con capacidad de reconstruir servicios rápidamente.

11. Conclusión

Node2Shell demuestra una vez más que los componentes que damos por sentados, como un descompresor integrado, pueden convertirse en la puerta de entrada de un ataque. Que Express 5 y fetch() expongan el fallo sin que el desarrollador llame nunca a Brotli es un ejemplo claro.

Lo esencial:

• Actualizar a Node.js 22.23.4, 24.22.1 o 26.12.1, reconstruir contenedores y reiniciar los procesos.
• Las ramas sin soporte (25.x, 23.x, 20.x y anteriores) no tienen parche: hay que migrar.
• Si no se puede actualizar de inmediato, limitar la exposición (por ejemplo, inflate: false, filtrado en el proxy y segmentación) y vigilar de cerca.
• Con la inclusión en el catálogo KEV de CISA, el riesgo ya no es teórico: conviene tratarlo como prioritario.
• A largo plazo, la mejor defensa es el inventario, el control del ciclo de vida, el mínimo privilegio y la monitorización.

12. Fuentes

• Aviso oficial de Node.js: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• Análisis de Akamai Security Intelligence Group, «Inside Node2Shell» (26 de octubre de 2026)
• Catálogo KEV de CISA (CVE-2026-111497, añadido el 27 de octubre)
• Resúmenes de Imperva, Aikido, Astra, Vendure y otros proveedores sobre el paquete de octubre de 2026