</> LBE Tech
← Todos los artículos
Node.jsBackendSeguridadTLSDNSnpm

Node.js 26.12.1, 24.22.1 y 22.23.4: actualiza el runtime correcto

La release de seguridad de Node.js del 21 de octubre actualiza ramas Current y LTS. Elige la rama y verifica el runtime del backend sin confundirlo con npm audit.

26 de octubre de 2026 · · 6 min de lectura
Tres ramas de Node.js con estados LTS o Current y una comprobación del runtime que atiende un backend

Actualizar Node.js no consiste en cambiar el número que muestra una terminal y dar por terminado el trabajo. La release de seguridad del 21 de octubre de 2026 llegó a tres ramas: 26.12.1 es Current, mientras 24.22.1 y 22.23.4 son LTS. La pregunta operativa es cuál de ellas está arrancando el proceso que atiende las solicitudes, y qué artefacto debe reconstruirse para que el parche llegue hasta allí.

Qué cambió en las tres ramas

Las tres notas de release se presentan como actualizaciones de seguridad. Comparten correcciones para rechazar direcciones IP no canónicas durante TLS (CVE-2026-106069 y CVE-2026-106072), validar entradas DNS con bytes nulos (CVE-2026-105482), Brotli (CVE-2026-111497), un guard del agente HTTP sin I/O (CVE-2026-105481), cachés criptográficas entre snapshots (CVE-2026-106074) y realpathSync bajo el modelo de permisos (CVE-2026-106073).

La matriz no es idéntica. CVE-2026-105483, una regresión de normalización de IP en TLS, aparece en las notas de 26.12.1 y 24.22.1, pero no está enumerada en la nota de 22.23.4. La versión 26 también enumera una corrección de cabeceras ZIP locales inválidas en zlib (CVE-2026-106070) que no aparece en las notas de 24 y 22. “No enumerada en esa nota” describe la evidencia disponible; no equivale a “no afectada”. Para una decisión sobre una rama distinta, consulta su changelog y el soporte del proveedor.

Rama Versión de la release Estado al 26 de octubre Decisión práctica
Node 22 22.23.4 LTS Mantenerla si es la rama compatible que ya ejecuta el servicio y aplicar su parche.
Node 24 24.22.1 LTS Preferirla para producción cuando el servicio ya está preparado para esa rama.
Node 26 26.12.1 Current Tratarla como una decisión de compatibilidad, no como un salto urgente solo por el número mayor.

El calendario oficial indica que las aplicaciones de producción deben usar una rama Active LTS o Maintenance LTS. Por eso una actualización de seguridad no obliga a pasar de 22 o 24 a Current 26. Una migración mayor puede requerir revisar módulos nativos, OpenSSL, TLS, DNS y pruebas de compatibilidad por separado.

Comprueba el runtime que atiende tráfico

node --version describe el ejecutable que encuentra el PATH de esa shell. Puede ser útil para revisar una imagen o un host, pero no demuestra que un worker de systemd, PM2, un contenedor o una plataforma gestionada use el mismo binario. El proceso que quieres validar debe registrar, mediante el mecanismo de observabilidad que ya use el servicio, al menos process.version, process.execPath y las versiones relevantes de process.versions.

Este diagnóstico local ayuda a detectar una discrepancia sin exponer datos en una ruta pública:

node --version
node -p 'JSON.stringify({version: process.version, execPath: process.execPath, openssl: process.versions.openssl}, null, 2)'

La primera orden y la segunda deben ejecutarse en el mismo artefacto que se desea comprobar. Si estás construyendo una imagen, repite el diagnóstico dentro de la imagen candidata y conserva su tag y digest. Si el proceso lo inicia un gestor, revisa la ruta del ejecutable y el worker nuevo después del reinicio. En un servicio gestionado, usa sus controles administrativos; no conviertas process.versions en un endpoint abierto.

Una forma compacta de leer la diferencia desde el propio proceso es:

console.log({
  node: process.version,
  executable: process.execPath,
  openssl: process.versions.openssl,
  v8: process.versions.v8,
});

Este código no prueba por sí solo un despliegue remoto. Su valor está en colocarlo donde ya se registra el arranque del servidor, con el control de acceso y la retención habituales.

Actualiza el artefacto correcto

La corrección no llega al proceso por ejecutar npm install. npm audit puede ayudar a revisar dependencias declaradas por la aplicación, pero no sustituye actualizar el ejecutable, el paquete del sistema, el instalador o la imagen base de Node.

Primero identifica cómo se fija la versión: un administrador de versiones, un paquete del sistema, una imagen base, un instalador administrado o una configuración de la plataforma. Después, actualiza ese punto de control y reconstruye el artefacto. El cambio debe producir un nuevo proceso con la versión objetivo, no solo dejar un binario nuevo junto a un worker viejo.

Un flujo conservador tiene estas comprobaciones:

  1. Registra la rama actual, el ejecutable, el tag o digest de imagen y el gestor que inicia el servicio.
  2. Elige el parche de la misma rama soportada: 22.23.4, 24.22.1 o 26.12.1 si una migración a Current ya está aprobada.
  3. Actualiza la referencia del artefacto, reconstruye y verifica las sumas o el mecanismo de integridad que use el equipo.
  4. Ejecuta la suite existente y una prueba acotada de las rutas TLS, DNS y HTTP que el servicio ya utiliza, sobre fixtures controlados.
  5. Despliega el candidato con el procedimiento normal, confirma la versión dentro del proceso nuevo y comprueba que no quede un worker anterior atendiendo tráfico.
  6. Conserva el artefacto previo como rollback operativo, pero no lo vuelvas a poner al frente si la revisión de seguridad que motivó el cambio sigue sin corregirse.

La prueba funcional debe comparar el comportamiento esperado de la aplicación: códigos de respuesta, errores, logs y métricas. No hace falta crear payloads ni probar contra dominios o servicios de terceros para verificar una actualización de runtime.

Qué puede y qué no puede concluir la matriz

Las notas de release son una guía concreta para identificar cambios del binario, no una certificación de la aplicación completa. Una corrección en TLS no revisa la política de certificados de tu servicio; una corrección de DNS no valida los resolvers o timeouts que hayas configurado; una actualización de OpenSSL y certificados raíz tampoco prueba todas las rutas criptográficas de la aplicación.

La ausencia de una CVE en una nota de rama no prueba que esa rama no esté afectada. Comprueba la documentación de la rama, los avisos del proveedor y la cadena de construcción que distribuya el runtime. Del mismo modo, npm audit no es un detector de la versión de Node: son inventarios distintos y requieren remediaciones distintas.

El resultado que buscas es más preciso que “Node está actualizado”: el artefacto que atiende tráfico pertenece a una rama soportada, usa la revisión corregida de esa rama, superó las pruebas acotadas del servicio y puede identificarse de nuevo después del siguiente reinicio.

Fuentes primarias

También puede interesarte

Comentarios

Cargando…