Parche de seguridad Node.js (octubre 2026)
El 21 de octubre de 2026 Node.js publicó una release de seguridad con 10 CVEs para las ramas 26.x, 24.x y 22.x. La más grave, CVE-2026-111497, es una escritura fuera de límites en el descompresor Brotli que permite ejecución remota de código. Las versiones corregidas son v26.12.1, v24.22.1 y v22.23.4; 20.x y 25.x están en fin de vida y no reciben parche.
¿Tienes esta vulnerabilidad? Actualizamos Node.js en tus servidores, imágenes Docker y pipelines, comprobamos que la aplicación sigue respondiendo igual y planificamos el cambio de rama si sigues en 20.x o 25.x.
$ node -vv22.20.0# 22.x se corrige en v22.23.4: afectado$ docker run --rm api:prod node -vv20.19.5# La imagen en producción va con otra: 20.x, sin parche$ cat .nvmrc22# El repo fija la rama, no el parchev26.12.1 · v24.22.1 · v22.23.4Diez CVEs en una release, cuatro de severidad alta
La release corrige cuatro vulnerabilidades altas, tres medias y tres bajas. A 21 de octubre no se había reportado explotación de ninguna.
CVE-2026-111497 es una escritura fuera de límites en el descompresor Brotli que permite ejecución remota de código. No hace falta llamar a zlib a mano para quedar expuesto: según Cyberkendra, Express 5 y fetch() descomprimen Brotli de forma automática.
Las otras tres altas tocan la red. CVE-2026-106069 y CVE-2026-105483 permiten saltarse la comprobación de hostname en certificados TLS, que es la que garantiza que tu aplicación habla con el servidor que cree cuando hace una petición HTTPS. CVE-2026-105482 hace que dns.resolve trunque nombres que contienen un carácter NUL.
La misma release rechaza las cadenas de certificados que usan las claves comprometidas de eMudhra, la autoridad certificadora india cuyos ocho certificados intermedios se generaron con claves débiles. Las ramas 20.x y 25.x, en fin de vida, no reciben nada de esto.
Versiones corregidas de Node.js
Si un servicio corre con una versión anterior a la de su rama, está afectado. En 20.x y 25.x no hay versión corregida: la salida es cambiar de rama.
| Rama | Corregida en | Nota |
|---|---|---|
| 26.x | v26.12.1 | |
| 24.x | v24.22.1 | |
| 22.x | v22.23.4 | |
| 25.x | Sin parche | Fin de vida: pasar a 26.x |
| 20.x | Sin parche | Fin de vida: pasar a 22.x o 24.x |
Revisa esto
- Tienes APIs, backends o renderizado en servidor (Next.js, Nuxt, Astro, NestJS, Express) corriendo en Node.js.
-
node -ven el servidor, o dentro de la imagen Docker, da una versión anterior a la de tu rama. - Tu Dockerfile usa una etiqueta como
node:22y la imagen no se ha reconstruido: sigue con la versión que había al construirla. - Algún servicio sigue en 20.x o 25.x: no habrá parche para esas ramas.
- Tu aplicación descomprime Brotli (con
fetch(), Express 5 o un proxy propio) o hace peticiones HTTPS a terceros.
Si sigues en 20.x o 25.x
Node.js no ha publicado mitigaciones temporales para esta release. En una rama sin soporte, lo único que corrige los fallos es salir de ella.
- 01 Las ramas en fin de vida no reciben esta corrección ni las que vengan después.
- 02 Pasar de 20.x a 22.x o 24.x suele obligar a revisar dependencias con módulos nativos y a probar el build completo.
- 03 Mientras dura la migración, conviene saber qué endpoints aceptan cuerpos comprimidos y qué servicios descargan contenido de fuera: son los primeros que hay que mover.
Siete pasos, en este orden
Aplicamos el mismo procedimiento en cada servidor: primero saber qué versión hay en cada sitio, después corregir y al final comprobar que nadie entró antes del parche.
Inventario de versiones
Localizamos dónde corre Node.js: servidores, imágenes Docker, funciones serverless, runners de CI y el .nvmrc o el campo engines de cada repositorio. Cada sitio puede llevar una versión distinta.
Mitigación inmediata
Sin mitigación oficial, empezamos por los servicios más expuestos: los que aceptan cuerpos con Brotli o descargan contenido de terceros van primero en la cola.
Actualización
Subimos a v26.12.1, v24.22.1 o v22.23.4, reconstruimos las imágenes y fijamos la versión en Dockerfile, .nvmrc y CI. Si estás en 20.x o 25.x, planificamos el salto de rama.
Verificación
Comprobamos la versión dentro del contenedor que está en producción, pasamos los tests y revisamos que las llamadas HTTPS a terceros sigan validando certificados.
Revisión de indicios de compromiso
Revisamos logs de la aplicación y del sistema en busca de caídas del proceso, reinicios sin explicación y procesos o ficheros que no deberían estar ahí.
Rotación de secretos, si procede
Si hay señales de acceso, rotamos las variables de entorno sensibles: claves de API, credenciales de base de datos y tokens.
Vigilancia de nuevos avisos
Dejamos anotada la versión de cada servicio y la fecha de fin de vida de su rama, para que la siguiente release de seguridad empiece desde ese inventario.
Dónde se queda Node.js sin actualizar
¿Tienes servicios en Node 20 y no sabes cuánto cuesta moverlos?
Consultoría gratuita →Preguntas frecuentes sobre la release de seguridad de Node.js
¿Qué versiones de Node.js corrigen CVE-2026-111497?
Uso Node 20, ¿estoy afectado?
¿Me afecta si no uso Brotli?
¿Basta con cambiar la imagen base de Docker?
Cuéntanos dónde corre tu Node.js
Empezamos por el inventario: qué versión lleva cada servicio, cuál hay que mover primero y qué rama necesita una migración.
Cuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.