Node.js publicó dos versiones con un día de diferencia: la 24.21.0 «Krypton» (LTS) el 8 de septiembre de 2026 y la 26.8.2 (Current) el 9 de septiembre. Ninguna rompe nada, pero ambas renuevan la cadena de confianza TLS y la línea LTS incorpora la carga de claves privadas a través de los STORE loaders de OpenSSL. Para un parque en producción es una actualización de seguridad e higiene criptográfica, no una versión para contemplar de lejos.
Dos líneas, dos publicaciones en un fin de semana
Cada rama sigue su propio calendario: la 24.x es la línea LTS recomendada en producción y la 26.x es la línea Current, donde las novedades llegan primero. La tabla resume lo que incorpora cada una.
| Versión | Línea | Fecha | OpenSSL | Undici | Raíces |
|---|---|---|---|---|---|
| 24.21.0 «Krypton» | LTS | 8 sep. 2026 | 3.5.8 | 7.29.1 | NSS 3.126 |
| 26.8.2 | Current | 9 sep. 2026 | 3.5.8 | 8.10.2 | desde 26.8.x |
La línea LTS mantiene Undici en la serie 7.x para preservar la compatibilidad, mientras que Current sigue la 8.x. OpenSSL, en cambio, se alinea en 3.5.8 en ambos lados.
Una cadena de confianza puesta al día
El cambio más amplio afecta a la confianza TLS saliente. La 24.21.0 incluye el almacén de certificados raíz de Mozilla en su revisión NSS 3.126, y OpenSSL pasa a 3.5.8. En la práctica, un servicio que llama a API de terceros por HTTPS resincroniza su almacén de raíces con las autoridades que el resto del ecosistema considera válidas: autoridades añadidas, autoridades retiradas, restricciones endurecidas. Un runtime congelado en raíces antiguas acaba rechazando un certificado legítimo, o confiando en una autoridad que Mozilla descartó hace tiempo.
En una línea LTS, la tentación es aplazar las subidas de versión menores. Los certificados raíz son la excepción: dejarlos envejecer acumula una deuda que se paga un día en errores UNABLE_TO_VERIFY_LEAF_SIGNATURE difíciles de diagnosticar. Comprobar las versiones incluidas lleva segundos.
node -p "process.versions.openssl" # 3.5.8
node -p "process.versions.undici" # 7.29.1 en LTS 24.x, 8.10.2 en 26.x
node -e "console.log(require('tls').rootCertificates.length)" # racines NSS embarquéesCargar una clave privada sin dejarla en el disco
La novedad marcada como semver-minor de la 24.21.0 es el soporte de claves privadas cargadas mediante los STORE loaders de OpenSSL (aportación de Filip Skokan). Donde antes una clave debía existir como archivo PEM legible por el proceso, OpenSSL 3 sabe exponer una clave a través de un proveedor: un módulo PKCS#11 respaldado por un HSM, un almacén del sistema, un agente dedicado. La clave permanece entonces detrás de su proveedor y el código de la aplicación solo maneja una referencia.
Una clave privada que nunca toca el sistema de archivos es una clave que ninguna fuga de volumen compromete.
El punto de entrada se configura del lado de OpenSSL, mediante el archivo de configuración que activa el proveedor deseado. Node.js se apoya después en ese proveedor para resolver la clave al establecer el contexto TLS.
# openssl.cnf : activer un fournisseur adossé a un HSM
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect
[default_sect]
activate = 1
[pkcs11_sect]
module = /usr/lib/ossl-modules/pkcs11.so
activate = 1Este cambio no es en absoluto obligatorio: la mayoría de los despliegues seguirán leyendo un archivo PEM. Sí abre, en cambio, una puerta esperada por los equipos sujetos a exigencias de conservación de secretos, que hasta ahora se negaban a ver una clave de producción en claro en un disco de aplicación.
Lo que la línea LTS gana de paso
La 24.21.0 retroporta varias incorporaciones semver-minor ya probadas en la línea Current. Los objetos Histogram de perf_hooks ganan pruebas de hipótesis estadística y una implementación revisada, net.BlockList mejora su rendimiento y util.MIMEType.parse() recibe una variante que devuelve null en lugar de lanzar una excepción ante una entrada no válida. Nada espectacular, pero otras tantas asperezas menos para el código que ya está en producción.
Lo que conviene recordar
Ambas publicaciones son de mantenimiento más que de anuncio: sin nueva API estructurante, pero con una cadena TLS resincronizada y una palanca de seguridad más para las claves privadas. Lo sensato es planificar la subida a la LTS 24.21.0 en los servidores de producción, priorizando los que abren conexiones HTTPS salientes hacia terceros. Desplegar Node.js en producción gana al tratar estas versiones menores como eslabones de seguridad, al mismo nivel que un parche de aplicación.
En mis servidores trato las raíces de certificados como las dependencias: una subida que no discuto. He visto demasiadas caídas «inexplicables» de webhooks reducirse a un runtime que llevaba tres años con un almacén de raíces antiguo. En cuanto a los STORE loaders, no los activaré en todas partes, pero para los proyectos donde la clave TLS tiene un valor real, sacar el PEM del disco es exactamente el arbitraje que recomiendo desde hace tiempo. El endurecimiento de un servidor empieza por este tipo de detalles. — Simon Janvier
Para profundizar: Node.js 24.21.0 & Node.js 26.8.2.
