Node.js 20 no recibirá nada el 11 de noviembre de 2026. Los lanzamientos de seguridad cubrirán únicamente las ramas 26.x, 24.x y 22.x, ya que Node.js 20 llegó al final de su vida útil (End-of-Life) el 30 de abril de 2026. Su último parche fue la versión 20.20.2, compilada el 24 de marzo. Desde entonces, se han publicado 33 CVE sin ninguna compilación para 20.x. Migre a 24 o 26 esta misma semana.
Dichas CVE se distribuyeron en tres versiones de seguridad que dejaron fuera a la rama 20. La cuarta llegará en pocos días, y el preanuncio clasifica su problema más grave como HIGH en todas las ramas con soporte.
Qué ocurrirá el 11 de noviembre y por qué Node.js 20 queda fuera
El proyecto Node.js publicará nuevas compilaciones de 26.x, 24.x y 22.x el miércoles 11 de noviembre de 2026 o poco después. Por ahora no hay detalles públicos sobre las CVE, y se mantendrán en privado hasta que salgan las nuevas versiones. Nuestra guía con cuenta regresiva para el lanzamiento de noviembre detalla el inventario del entorno de ejecución y los comandos para el día del parche, por lo que los omitiremos en este artículo.
Node.js 20 no figura en la lista porque el proyecto ha dejado de mantenerlo. Su página de End-of-Life es tajante: cuando los nuevos lanzamientos de seguridad solucionan problemas, «incluso si la misma vulnerabilidad afecta a líneas de versiones que han llegado al final de su vida útil (EOL), no habrá ningún nuevo lanzamiento para ellas».
El aviso de seguridad añade otra advertencia fundamental: «Las versiones que han llegado al final de su vida útil siempre se ven afectadas cuando se produce un lanzamiento de seguridad».
Lo que Node.js 20 ya se ha perdido
Se han publicado tres versiones de seguridad desde que la rama 20 alcanzó el final de su ciclo de vida. Ninguna incluye una compilación para 20.x.
| Aviso | CVE | Alta | Media | Baja | Corregido en |
|---|---|---|---|---|---|
| 18 de junio de 2026 | 12 | 2 | 6 | 4 | 26.3.1, 24.17.0, 22.23.0 |
| 29 de julio de 2026 | 11 | 3 | 5 | 3 | 26.5.1, 24.18.1, 22.23.2 |
| 21 de octubre de 2026 | 10 | 4 | 3 | 3 | 26.12.1, 24.22.1, 22.23.4 |
| Total | 33 | 9 | 14 | 10 | Sin compilación para 20.x |
El código que modifican estas correcciones es exactamente el que ejecuta un servidor de API de forma continua:
- Comprobaciones de nombre de host en TLS. Tanto en junio como en octubre se corrigieron fallos que permitían validar un certificado para un host incorrecto.
- HTTP/2. Las correcciones de severidad alta de julio incluyen una vulnerabilidad de tipo use-after-free en el heap y un fallo de agotamiento remoto de memoria.
- DNS. En octubre se solucionó un problema por el cual
dns.resolve*()truncaba los nombres de host ante un byte NUL, lo que permitía burlar listas de permitidos. - Compresión. En octubre se corrigió una escritura fuera de límites en el decodificador de Brotli que podía desembocar en ejecución remota de código. Lo analizamos en nuestra revisión del RCE en Brotli.
Lea esa lista con atención. El proyecto no evalúa las ramas descontinuadas, por lo que sus avisos de seguridad solo mencionan las versiones con soporte oficial. Algunos de estos errores residen en código que la versión 20 podría no contener: una de las CVE de octubre es una regresión acotada exclusivamente a 26.x y 24.x. Por lo tanto, el estado real de cada CVE en Node.js 20 es sin parchear y sin evaluar. Nadie le ha garantizado que esté a salvo, y nadie va a comprobarlo.
El encadenamiento de vulnerabilidades empeora aún más la situación. La corrección de DNS de octubre completa un parche de junio, y otra corrección de julio complementa una de junio. Cada parche posterior se construye sobre una base de la que usted carece.
«Pero si todavía funciona»
Funciona, y ese es precisamente el problema.
Un entorno de ejecución descontinuado no falla de golpe. node -v sigue mostrando la misma versión, las pruebas pasan y los paneles de monitorización se mantienen en verde. El riesgo aparece en lugares a los que no suele prestar atención:
- El propio parche sirve de mapa. Las correcciones, los avisos y los commits se publican al mismo tiempo, por lo que cualquiera puede ver con exactitud qué cambió en una versión con soporte y comprobar si ese mismo código existe en la rama 20.
- Su plataforma podría seguir desplegándolo. AWS Lambda marcó
nodejs20.xcomo obsoleto el 30 de abril de 2026, pero no bloqueará la creación de funciones hasta el 29 de julio de 2027 ni las actualizaciones hasta el 31 de agosto de 2027. - Los paquetes y las auditorías avanzan. El proyecto Node.js advierte de que los paquetes más populares van retirando con el tiempo el soporte para versiones descontinuadas, y muchas auditorías del sector prohíben explícitamente el uso de entornos sin mantenimiento.
Elija un destino: Node.js 24 o 26, pero no 22
Migre a la versión 24 esta semana si necesita el camino más rápido. Elija la 26 si puede asumir más cambios ahora y busca el ciclo de vida más largo. Descarte la versión 22: aunque recibirá la corrección de noviembre, su soporte concluye el 30 de abril de 2027 (en menos de seis meses), por lo que tendría que repetir todo este proceso en primavera.
| Rama | Estado | Última versión al 5 de nov. | Fin del soporte | Ideal para |
|---|---|---|---|---|
| 26.x «Lithium» | LTS activa desde el 28 de oct. de 2026 | 26.13.0 | 30 de abr. de 2029 | Servicios que pueda volver a probar por completo ahora |
| 24.x «Krypton» | LTS de mantenimiento desde el 20 de oct. de 2026 | 24.22.2 | 30 de abr. de 2028 | La salida segura más rápida desde la versión 20 |
| 22.x «Jod» | LTS de mantenimiento | 22.23.4 | 30 de abr. de 2027 | No merece la pena migrar a ella hoy |
Las fechas proceden del calendario de lanzamientos de Node.js. Compruebe su plataforma antes de dar el paso. En Lambda, por ejemplo, el entorno de ejecución de Node.js 26 se encuentra en vista previa pública y no está cubierto por su SLA, por lo que la versión 24 es actualmente la opción más segura para producción en ese entorno.
Pasos para la migración y qué cosas dejarán de funcionar
Toda la información de esta tabla procede de las notas de lanzamiento oficiales de 22.0.0, 24.0.0, 25.0.0 y 26.0.0, además de la guía de migración de v22 a v24. Es una selección resumida y orientada a servicios de API, no el registro completo de cambios.
| Introducido en | Cambio | A quién afecta |
|---|---|---|
| 22 | import ... assert { type: 'json' } removed; use with |
Código ESM que importe JSON |
| 22 | crypto.createCipher() and createDecipher() removed |
Código de cifrado heredado |
| 23 and 24 | No prebuilt 32-bit Windows or 32-bit armv7 Linux binaries; macOS 13.5 minimum | Servidores antiguos y dispositivos edge |
| 24 | OpenSSL 3.5 at security level 2: RSA, DSA, and DH keys under 2048 bits, ECC keys under 224 bits, and RC4 are prohibited | mTLS y servidores upstream antiguos |
| 24 | tls.createSecurePair removed; url.parse() runtime-deprecated |
Código de red heredado |
| 24 | Stricter fetch() compliance, AbortSignal validation, stream and pipe errors now throw |
Clientes HTTP y proxies |
| 24 | V8 13.6; addons may need C++20 | Módulos nativos |
| 25 (if targeting 26) | SlowBuffer and fs.F_OK, R_OK, W_OK, X_OK removed; Corepack no longer ships |
Utilidades antiguas, Yarn o pnpm mediante Corepack |
| 25 (if targeting 26) | IP address as TLS servername moved to End-of-Life |
Clientes que conecten mediante IP |
| 26 | _stream_* modules and writeHeader() removed; module.register() runtime-deprecated; Undici 8 |
Código de streams antiguo, loaders personalizados |
La fila de OpenSSL es la que puede dar problemas de forma silenciosa: su código no cambia en absoluto, pero el handshake con un sistema externo antiguo falla en tiempo de ejecución.
En una rama, actualice .nvmrc, engines, su Dockerfile y su CI a la versión de destino (en un entorno limpio, consulte la guía de instalación de Node.js). Luego reinstale para recompilar los módulos nativos, busque APIs eliminadas, ejecute los codemods oficiales e inicie el servicio con el rastreo de obsolescencias activado:
nvm install 24 && nvm use 24
rm -rf node_modules && npm ci
grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
--include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .
npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants
NODE_OPTIONS="--trace-deprecation" npm start
Revise manualmente el resultado de los codemods. El de createCipher es explícito: el código generado no puede descifrar datos cifrados con la API antigua, por lo que deberá planificar una migración de datos si los tiene.
El sitio web de Node.js aún no cuenta con una guía de migración de 24 a 26, por lo que le recomendamos consultar las notas de las versiones 25.0.0 y 26.0.0 para ese salto.
Compruebe que la API se comporta igual en la nueva versión
Las pruebas unitarias no muestran el impacto que una nueva pila TLS y un nuevo cliente HTTP tienen sobre el tráfico real. Ante un salto de dos o tres versiones mayores, conviene hacer una comparación del antes y el después con el servicio en ejecución, y esa es una tarea ideal para su agente de programación.
Apidog CLI permite que Claude Code, Codex o Cursor ejecuten sus suites de pruebas de Apidog directamente desde la terminal. Solo tiene que configurarlo una vez:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Luego, indíquele un único prompt a su agente:
My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.
El agente ejecutará la misma suite en ambos extremos de la migración:
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node20
# redeploy the service on the target line, restart it
apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
-r cli,junit --out-dir reports/node24
Dos factores garantizan que la comparación sea fiable:
- Nunca pase el parámetro
-k. Ese flag desactiva la validación SSL, lo que ocultaría precisamente los errores de TLS que necesita detectar. - Incluya las llamadas que su servicio realiza hacia otros sistemas (upstream). El rechazo de OpenSSL aparecerá como un error de API en un endpoint que dependa de un sistema externo antiguo; por lo tanto, pruebe esas rutas y no se limite a
/health.
Una vez superada la migración, mantenga la suite en su canal de CI/CD. La guía de CI/CD con Apidog CLI describe el flujo de trabajo, y el tutorial de Claude Code explica la configuración del agente.
Qué hacer si no puede migrar esta semana
Adquiera versiones parcheadas. La página de End-of-Life de Node.js menciona tres partners a través del programa OpenJS Ecosystem Sustainability Program: HeroDevs ofrece Never-Ending Support con parches de seguridad; TuxCare, mediante Endless Lifecycle Support, adapta parches para versiones en fin de vida; y NodeSource ofrece evaluaciones de actualización y soporte. El proyecto califica esto como una solución temporal, y ciertamente lo es.
Reduzca la superficie de exposición del proceso. Estas medidas disminuyen la exposición a los tipos de fallos descritos anteriormente, aunque no solucionan nada de raíz:
- Termine TLS y HTTP/2 en un proxy o balanceador de carga con soporte activo, y comuníquese con Node.js mediante HTTP/1.1 sin cifrar en una red privada.
- Deje de descomprimir Brotli procedente de orígenes no confiables, tanto en las peticiones entrantes como en el contenido obtenido de forma externa.
- Rechace nombres de host que contengan bytes NUL o representaciones de IP no canónicas antes de cualquier comprobación de lista de permitidos o llamada saliente.
- Aísle el servicio: credenciales con el mínimo privilegio, tráfico de salida restringido y sin secretos compartidos con servicios parcheados.
Documente formalmente el riesgo. Asigne un responsable, una fecha límite para la migración y los controles de mitigación implementados, de modo que lo «temporal» tenga un fin definido.
Preguntas frecuentes (FAQ)
¿Node.js 20 sigue teniendo soporte? No. Llegó al final de su ciclo de vida (End-of-Life) el 30 de abril de 2026. La última versión es la 20.20.2 del 24 de marzo de 2026, y el proyecto no publicará ninguna otra.
¿Es Node.js 20 vulnerable a los fallos del 11 de noviembre? Los detalles de las CVE aún no son públicos, por lo que nadie puede asegurar cuáles le afectan. Sin embargo, el aviso oficial señala que las versiones descontinuadas siempre se ven afectadas cuando se produce un lanzamiento de seguridad, y el proyecto no las evalúa individualmente.
¿Debería actualizar a Node.js 22 en su lugar? No. Aunque es el salto más pequeño, su ciclo de vida concluye el 30 de abril de 2027. Migrar a 24 le proporciona un año adicional de soporte, y pasar a 26 le otorga dos años más.
¿Node.js 24 o 26? Elija la 24 si necesita salir del paso esta misma semana o si su infraestructura todavía no es totalmente compatible con la versión 26. Elija la 26 si puede probarlo todo de nuevo en este momento, ya que tendrá soporte hasta el 30 de abril de 2029.
Estoy utilizando Node.js 25. ¿Aplica esto a mi caso? Sí. Node.js 25 llegó al final de su vida útil el 1 de junio de 2026, con la versión 25.9.0 como su última compilación. Tampoco recibirá correcciones en noviembre, y la versión 26 está a solo una versión mayor de distancia.