El 3 de noviembre de 2026, el proyecto Node.js anunció que publicará nuevas versiones de las líneas 26.x, 24.x y 22.x "el miércoles 11 de noviembre o poco después". El aviso clasifica como alto el fallo más grave corregido en cada una de las tres líneas. Los detalles técnicos solo se publican junto con las versiones, como es habitual en el proyecto.
El propio comunicado recuerda que las versiones sin soporte siempre se ven afectadas cuando hay una versión de seguridad. No reciben la corrección.
Qué versiones reciben la corrección
Según el calendario oficial, recopilado en endoflife.date, la situación de las líneas más usadas es esta:
Línea | Situación en noviembre de 2026 | Fin de las correcciones |
|---|---|---|
Node 26 | LTS activo desde el 28 de octubre | 30 de abril de 2029 |
Node 24 | LTS en mantenimiento desde el 20 de octubre | 30 de abril de 2028 |
Node 22 | LTS en mantenimiento | 30 de abril de 2027 |
Node 25 | sin soporte desde el 1 de junio de 2026 | sin corrección |
Node 20 | sin soporte desde el 30 de abril de 2026 | sin corrección |
Quien está en 22, 24 o 26 recibe una versión de corrección dentro de la misma línea, que suele ser una actualización pequeña. Quien sigue en Node 20, o se quedó en la 25 después de su fin en junio, no recibe nada el 11 de noviembre: el fallo sigue abierto hasta que la aplicación cambie de línea.
Es la segunda versión de seguridad en tres semanas. La del 21 de octubre corrigió, entre otros, un fallo alto en el que dns.resolve*() truncaba nombres con un carácter NUL (CVE-2026-105482) y dos fallos altos en la verificación del nombre del certificado TLS para direcciones IP escritas de forma no canónica (CVE-2026-105483 y CVE-2026-106069). El aviso de noviembre no dice si los nuevos fallos tienen relación con esos.
Quién tiene que moverse
Cualquier aplicación que ejecute Node.js en producción: APIs, workers de colas, renderizado en el servidor de frameworks como Next.js y Astro, y también el pipeline de build, que ejecuta Node aunque el sitio final sea estático. El riesgo real depende del módulo afectado, que todavía no se ha divulgado.
En una plataforma gestionada, quien actualiza el runtime es el proveedor. Conviene confirmar en su documentación cuándo está disponible la versión corregida y si el cambio es automático o exige un nuevo despliegue. Con imágenes Docker propias, la corrección solo llega cuando la imagen se reconstruye a partir de una etiqueta actualizada; una imagen antigua en ejecución sigue con el binario antiguo.
Qué hacer antes del 11 de noviembre
Hasta el próximo miércoles, la tarea es saber dónde corre cada versión y asegurarse de que una actualización de parche pueda llegar a producción en uno o dos días:
- revisar la versión de Node de cada servicio en
.nvmrc, el campoenginesdepackage.json, la líneaFROMde los Dockerfiles, la configuración del CI y la del proveedor; - confirmar que el pipeline reconstruye imágenes y ejecuta las pruebas sin pasos manuales;
- reservar una ventana el 11 o el 12 de noviembre para aplicar las nuevas versiones, después de leer el comunicado completo.
Para quien está en Node 20 o 25, la decisión es otra: actualizar el parche no resuelve nada, y la migración a 24 o 26 pasa a tener plazo. Escribí sobre por qué una versión con soporte también exige decidir cuándo migrar. En las líneas 20 y 25 el aplazamiento ya tiene un costo, porque cada versión de seguridad hace público un fallo más que no se corregirá en ellas.
Lo que todavía no se sabe
El aviso no dice cuántos fallos son, qué módulos afectan, si tienen CVE asignado ni si alguno se está explotando. Tampoco dice si la versión incluye actualizaciones de dependencias integradas, como OpenSSL o Undici, algo que ocurrió en octubre. La fecha puede moverse, porque el texto dice "o poco después". En octubre, el propio comunicado se actualizó con la lista de fallos cuando salieron las versiones, así que los detalles deberían aparecer allí.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
