Node.js 20 dejó de recibir actualizaciones de seguridad el 30 de abril de 2026, tal y como marcaba su calendario de soporte desde que entró en fase de mantenimiento en octubre de 2024. La aplicación sigue funcionando exactamente igual al día siguiente: no hay un aviso en pantalla ni un error que la detenga. El problema aparece semanas después, cuando se publica un fallo de seguridad que sí se corrige en las versiones activas y que Node.js 20 ya no va a recibir. Si tu equipo técnico o tu proveedor todavía despliega sobre esta versión, esto es lo que cambia y cuándo conviene mover el proyecto.
¿Qué significa que Node.js 20 esté sin soporte? Que el proyecto Node.js dejó de publicar parches de seguridad para esa versión el 30 de abril de 2026: cualquier vulnerabilidad que se descubra a partir de esa fecha se corrige en las versiones 22, 24 y superiores, pero no en la 20, que queda expuesta mientras siga en producción.
El fin de soporte de Node.js 20
El ciclo de vida de Node.js sigue un patrón fijo desde hace años: cada versión par entra en soporte a largo plazo (LTS) durante doce meses de mantenimiento activo y otros dieciocho de mantenimiento reducido, con parches limitados a fallos críticos y de seguridad. Node.js 20, con nombre en clave Iron, entró en LTS en octubre de 2023, pasó a mantenimiento en octubre de 2024 y agotó su ventana el 30 de abril de 2026, según el calendario oficial de versiones. A partir de esa fecha no hay build oficial, ni parche de seguridad, ni backport de ningún tipo: el proyecto simplemente deja de tocar esa rama. Algo parecido a lo que pasó con PHP 8.1 cuando se quedó sin soporte: el corte no es funcional, es de seguridad, y por eso pasa desapercibido más tiempo del que debería. Las versiones que sí reciben soporte hoy son la 22 (Jod), en mantenimiento hasta abril de 2027, y la 24 (Krypton), en soporte activo hasta octubre de 2026 y en mantenimiento hasta 2028. Cualquier proyecto desplegado sobre la 20 sigue arrancando y sirviendo tráfico sin ningún cambio visible.
Vulnerabilidades de Node.js sin parchear
El último parche que sí llegó a Node.js 20 salió el 24 de marzo de 2026, con la versión 20.20.2: corrigió dos fallos de severidad alta, cuatro medios y dos bajos, según el aviso oficial de seguridad de esa fecha. Fue el último tren. La siguiente ronda de seguridad, publicada el 18 de junio de 2026, ya no incluyó la rama 20 en el listado de versiones parcheadas: solo cubrió la 22, la 24 y la recién nacida 26. Cualquier vulnerabilidad de esa ronda que afecte también al motor de la versión 20 se queda sin corregir de forma permanente, salvo que alguien pague un soporte extendido de terceros.
Los CVE de alta severidad de junio quedaron fuera
La ronda de junio de 2026 corrigió doce fallos: dos de severidad alta, seis medios y cuatro bajos, según el boletín de junio. Los dos altos son concretos: CVE-2026-48933, un desbordamiento de enteros en WebCrypto AES que permite tumbar el proceso con una petición manipulada, y CVE-2026-48618, un fallo en la validación de comodines TLS que abre una vía de suplantación de certificado. Ninguno de los dos es exclusivo de las versiones nuevas: son fallos del núcleo de Node.js, presentes también en la rama 20, que simplemente no los va a corregir. Un escáner de dependencias seguirá marcando el proyecto como vulnerable mes tras mes, sin que exista una actualización que lo resuelva.
Diferencias técnicas entre Node 20 y Node 22
Migrar no es solo cambiar un número de versión en el archivo package.json. Node.js 22 trae el motor V8 12.4, con soporte estable para require() de módulos ES y para Web Storage en local, además de una gestión de permisos ampliada que en la 20 seguía en fase experimental. Node.js 24 sube a V8 13.x e incorpora mejoras de rendimiento en el recolector de basura que se notan en procesos con mucha memoria retenida, como los workers de generación de PDF o los pipelines de imágenes. Ninguno de los dos cambios rompe una aplicación típica de Express o Fastify, pero sí afecta a paquetes nativos compilados contra una versión concreta de V8 y a librerías de bajo nivel que dependen de APIs marcadas como experimentales en la 20.
Cambios en el motor V8 y en las APIs nativas
El salto de mayor impacto práctico es el de las dependencias con partes en C++ compiladas para una ABI concreta: bcrypt, sharp o los conectores nativos de bases de datos necesitan una build específica para Node 22 o 24, y sin ella la instalación falla o cae a compilar desde código fuente, con las herramientas de compilación que eso exige en el servidor. Los módulos puramente en JavaScript no suelen dar problemas. La forma de detectarlo antes de mover producción es ejecutar la batería de tests con la nueva versión en un entorno de preproducción y revisar el registro de compilación de cada dependencia nativa, no solo el resultado final del pipeline.
Ruta de migración sin parar producción
La migración se hace mejor en pasos pequeños que en un cambio único de versión. El orden que menos incidencias genera, tanto para un equipo interno como para un proveedor externo, es este:
- Fijar la versión objetivo, la 22 si el proyecto prioriza estabilidad o la 24 si necesita las últimas APIs, y actualizarla primero en un entorno de desarrollo, nunca directamente en el servidor de producción.
- Revisar el archivo de dependencias con npm outdated y actualizar una a una las que tengan build nativa, comprobando que cada una publica soporte explícito para la nueva versión.
- Ejecutar la suite de tests completa y, si no existe, cubrir al menos las rutas críticas de login, checkout y envío de formularios antes de tocar nada en el servidor real.
- Desplegar en un entorno idéntico al de producción durante al menos una semana con tráfico real replicado, antes de mover el balanceador definitivo.
En equipos sin desarrollador interno, este es el momento de apoyarse en un equipo de desarrollo de software a medida: postergar la migración es la manera más rápida de acumular deuda técnica que el equipo paga después con intereses, y cambiar de versión de runtime sin pruebas previas es la causa más común de caídas tras una migración que, sobre el papel, parecía trivial.
Mitigaciones si la migración no es inmediata
No todos los proyectos pueden moverse en las próximas semanas. Una tienda online sobre Node 20 con pasarelas de pago a medida necesita validar cada integración antes de tocar el runtime. Un desarrollo a medida en el sector industrial, con conexiones a sensores o a un ERP por API, arrastra librerías propietarias que no siempre publican versión compatible con la 22. Un despliegue de servicios profesionales con formularios de captación y CRM conectado puede permitirse parar unas horas fuera de su franja de más tráfico, algo que una tienda no puede hacer un viernes por la tarde. En los tres casos, mientras la migración no llega, hay medidas que reducen la exposición sin tocar el código: cerrar puertos que no necesiten estar abiertos a internet, poner el proceso detrás de un proxy inverso actualizado y revisar los logs de acceso con más frecuencia de la habitual.
Qué cubre un soporte de pago sin migrar
Existen proveedores especializados que mantienen builds de Node.js 20 con parches de seguridad aplicados después de la fecha oficial de corte, a cambio de una cuota mensual por servidor. Cubren solo vulnerabilidades críticas y altas, no funcionalidad nueva, y están pensados como un puente de meses, no como sustituto permanente del soporte oficial. Una auditoría de sistemas puede confirmar antes que nada qué dependencias exactas dependen todavía de la versión 20 y cuáles ya funcionan igual en la 22, para no pagar ese puente más tiempo del necesario.
Preguntas frecuentes sobre Node.js 20
¿Qué pasa si sigo usando Node.js 20?
La aplicación sigue funcionando sin ningún cambio visible: no hay aviso ni bloqueo. El riesgo es acumulativo, porque cada vulnerabilidad que se publique a partir de ahora para el núcleo de Node.js se corrige en las versiones activas y no en la 20, que queda expuesta de forma permanente mientras siga en producción.
¿Cuánto se tarda en migrar a Node.js 22?
Depende del número de dependencias con partes nativas. Un proyecto sencillo, sin librerías compiladas, se mueve en un par de días de pruebas. Uno con conectores de base de datos, procesado de imágenes o generación de PDF a medida necesita entre una y tres semanas, contando la validación en preproducción antes de tocar el servidor real.
¿Conviene saltar directamente a Node.js 24?
Si el proyecto no depende de librerías nativas antiguas, sí: la 24 tiene ventana de soporte hasta 2028, dos años más que la 22. Si arrastra dependencias delicadas, la 22 es el salto más seguro ahora mismo y deja la 24 como siguiente parada en 2027.
¿Un escáner de vulnerabilidades detecta esto automáticamente?
Sí, si está actualizado: herramientas como npm audit o un escáner de dependencias en el pipeline de despliegue marcan la versión de Node.js como fin de vida y listan los CVE del núcleo que le afectan. El problema no es la detección, es que la corrección exige migrar, no solo actualizar un paquete.
Fuente: Node.js — Calendario oficial de versiones (nodejs.org)