Node.js corrige catorce fallos de seguridad en sus tres ramas LTS

El proyecto Node.js publicó el miércoles 11 de noviembre de 2026 versiones corregidas para sus tres ramas con mantenimiento activo: 22.x, 24.x y 26.x. El lote cierra catorce vulnerabilidades, siete de ellas de gravedad alta, y afecta sobre todo a los servidores HTTP/2 y TLS expuestos a clientes no confiables. Una fuga de memoria del servidor que expone claves privadas figura entre los casos más graves.

#Siete fallos de gravedad alta, de una fuga de claves TLS a una denegación de servicio en HTTP/2

Las versiones corregidas son 22.23.5, 24.22.3 y 26.13.1. El fallo más preocupante, CVE-2026-123864, surge de un problema de reentrada en TLSWrap::DoWrite(): puede filtrar memoria del servidor, incluidas las claves privadas TLS, directamente en el cuerpo de una respuesta HTTP. El tráfico en texto plano de node:http no se ve afectado; solo las conexiones cifradas corren riesgo.

Otros fallos de gravedad alta afectan a la pila HTTP/2: un cierre de conexión no autenticado mediante una aserción fallida en ~Http2Session(), sesiones que nunca se limpian tras un error de protocolo durante el cierre, y un use-after-free al desmontar un flujo. Otro más, CVE-2026-123872, permite a un cliente renegociar una sesión TLS 1.2 para cambiar el nombre del servidor y eludir la autenticación por certificado de cliente.

#Fallos de gravedad media y baja que también merecen revisión

El lote de gravedad media afecta en particular al modelo de permisos: las reglas con comodín --allow-fs-read y --allow-fs-write conceden más acceso del previsto, de modo que una regla como /etc/passwd.* termina permitiendo /etc/passwd. Otra entrada afecta a https.Agent, donde la reutilización de sesión TLS entre dos políticas de CA distintas elude la validación del certificado, junto con credenciales de proxy visibles en un mensaje de error y un fs.watch recursivo que expone, en macOS y Windows, nombres de archivo que deberían permanecer ocultos.

Una renegociación TLS 1.2 que cambia el nombre del servidor a mitad de la conexión basta para eludir una autenticación por certificado de cliente bien configurada.

#Actualizar sin esperar a una ventana de mantenimiento

Ninguna de las notas de versión documenta una solución alternativa para las ediciones sin corregir: actualizar sigue siendo la única remediación. Comprobar la versión actual lleva una sola línea, seguida de la instalación de la versión corregida de la rama en uso.

node -v
# según la rama utilizada
nvm install 22.23.5
nvm install 24.22.3
nvm install 26.13.1

Las dependencias internas llhttp, undici y sqlite también se actualizaron en este lote, sin cambios en V8. Las ramas que ya llegaron al final de su vida útil no reciben ninguna corrección.

#Un ritmo de parches que afecta a todo el ecosistema back-end

El calendario de versiones de Node.js, cuyo paso a un ciclo anual se confirmó a principios de noviembre con la rama 27 ya en alpha, no cambia nada en el tratamiento de las urgencias de seguridad en las líneas LTS existentes. Los equipos que orquestan estas actualizaciones ganan aplicando el mismo rigor al cifrado del transporte en otros contextos, como la supervisión del cifrado SMTP: un certificado mal validado tiene las mismas consecuencias, sea cual sea el protocolo.

#Lo que hay que recordar

Catorce fallos corregidos en una sola publicación, siete de ellos de gravedad alta y concentrados en HTTP/2 y TLS, justifican una actualización rápida de las tres ramas LTS de Node.js. Los equipos que exponen servidores HTTP/2 o TLS a clientes externos deben tratar este parche como prioritario; el resto debería revisar igualmente sus reglas del modelo de permisos antes del próximo ciclo de despliegue.

Para profundizar: las notas de versión completas las publica el proyecto Node.js en nodejs.org.