Node.js corrige 16 CVE: caídas en HTTP/2 y un fallo en HTTPS que filtra claves TLS

El 11 de noviembre el proyecto Node.js publicó versiones de seguridad para las tres líneas con soporte: 22.23.5 (Jod), 24.22.3 (Krypton) y 26.13.1 (Lithium). El lote abarca 16 CVE. Siete tienen severidad alta, seis media y tres baja, y de paso se actualizaron las dependencias incluidas llhttp, undici y sqlite.

Los problemas graves están en el código propio de Node para servidores HTTP/2, HTTPS y TLS. Un fallo permite que un cliente sin credenciales tire un servidor HTTP/2 con configuración por defecto. Otro permite que un cliente lea memoria que pertenece a otras conexiones, incluidas claves privadas TLS. El proyecto no informa de ataques conocidos, y CISA no ha añadido ninguno a su lista KEV. El aviso tampoco menciona ninguna solución alternativa: o se actualiza, o se sigue expuesto.

Los fallos que leeríamos primero

CVE-2026-123863 (CVSS 8.2, alta) es una aserción alcanzable en el cierre de sesiones HTTP/2. Lo que la dispara es bastante corriente: un servidor http2 estándar cuyo manejador envía una respuesta antes de que el cliente termine de enviar el cuerpo de la petición. Un cliente remoto puede usarlo para tumbar todo el proceso, tanto sobre TLS como en texto plano. Es una variante de CVE-2024-27983 que se escapó a la corrección anterior. Afecta a las versiones 24.x desde la 24.22.0 y 26.x desde la 26.9.0.

CVE-2026-123864 es el que me hizo dejar el café. Es un fallo de reentrada en la capa HTTPS de Node, y un atacante que nunca inicia sesión puede usarlo para leer datos de las conexiones de otras personas. Pueden ser sus peticiones, o puede ser la clave privada TLS de su servidor. Afecta a 22.x, 24.x y 26.x. El atacante necesita un manejador con una forma concreta: res.flushHeaders() invocado antes de que termine el cuerpo de la petición y, más tarde, res.end() con un fragmento no vacío. Además, alguna ruta debe devolver o almacenar el cuerpo de la petición, porque así regresan los bytes filtrados al atacante. node:http simple, sin TLS, no está afectado.

CVE-2026-123866 es un use-after-free en el cierre de streams HTTP/2. Puede enviar memoria liberada, o datos de respuesta de otra conexión, al otro extremo. Afecta a las tres líneas.

CVE-2026-123872 es más discreto, pero peligroso si usa mTLS. Durante la renegociación de TLS 1.2, un cliente puede cambiar el servername y trasladar una autenticación con certificado de cliente ya existente a un host con reglas de certificado de cliente más estrictas. Si un mismo proceso de Node sirve varios nombres de host con requisitos de certificado distintos, léalo dos veces.

Luego está CVE-2026-126051, una caída del servidor TLS que puede provocarse de forma remota. Afecta a servidores 24.x y 26.x que usen SNICallback, OCSPRequest, newSession, resumeSession o server.addContext().

Las líneas al final de su vida útil no reciben nada. Si todavía usa 20.x o 25.x, esta versión no corrige nada para usted.

¿Quién lo encontró? Chris Rohlf, trabajando con Claude y Anthropic Research, reportó 123863, 123864 y otros problemas de la versión, y Matteo Collina escribió la mayoría de las correcciones. Mi apuesta es que la búsqueda de fallos asistida por IA traerá más lotes grandes con muchos CVE, no menos. Planifique su proceso de parches con eso en mente.

Quién está realmente expuesto

El grupo en riesgo son los equipos que terminan HTTP/2 o HTTPS dentro del propio Node. Es un grupo más pequeño que «todos los que usan Node», pero mayor de lo que la mayoría supone.

Cuando construimos aplicaciones cloud-native para clientes empresariales, Node suele estar detrás de un balanceador o proxy inverso que gestiona TLS y habla HTTP/1.1 sin cifrar con la aplicación. En ese escenario el fallo de filtración de claves no le alcanza, porque node:http en texto plano queda fuera de alcance. Pero en nuestro trabajo con Docker nos topamos también con el otro tipo de servicio: una API de administración, un receptor de webhooks, una pequeña herramienta interna donde alguien llamó directamente a https.createServer o http2.createSecureServer porque era más rápido que montar un proxy. Nadie se acuerda de esos servicios a la hora de actualizar.

Tenga en cuenta además que 123863 funciona sobre HTTP/2 en texto plano. Si sus servicios se comunican por h2c dentro de un clúster, que TLS se gestione aguas arriba no le protegerá de la caída.

Los equipos móviles también deberían prestar atención. En nuestros proyectos nativos de iOS y Android el backend suele ser una API de Node, y hemos visto equipos activar HTTP/2 directamente en Node para el tráfico de la app y reducir la latencia. Si ese proceso puede tumbarse de forma remota, sus usuarios ven indicadores de carga y peticiones fallidas mientras su reporte de fallos no muestra nada raro en el dispositivo. Es un incidente confuso de depurar a las 2 de la madrugada.

En el plano de la seguridad, los fallos de divulgación de memoria me preocupan más que las caídas. Una caída aparece en su monitorización en minutos. Una filtración no avisa a nadie. En nuestras auditorías de pentesting para estudios de videojuegos, los peores hallazgos rara vez eran los ruidosos, sino las lecturas silenciosas para las que nadie tenía una línea de log. Y por nuestro trabajo contra DDoS con clientes de plataformas de viajes: cuando configuramos Cloudflare o Akamai delante de un origen, lo primero que probamos es si el origen sigue siendo accesible directamente. A menudo lo es. La configuración de su edge no sirve de nada si un atacante puede hablar con el proceso de Node sin pasar por ella.

Qué hacer hoy

1. Haga inventario de cada proceso de Node, no solo de la aplicación principal. Ejecute node -v dentro de cada imagen de contenedor que despliegue, incluidos cron jobs y sidecars. Una etiqueta de imagen base fijada no se actualiza sola, así que reconstruya y vuelva a desplegar.
2. Actualice a 22.23.5, 24.22.3 o 26.13.1, según su línea. No existe ningún indicador de configuración que haga desaparecer el problema.
3. Busque en su código el patrón de la filtración HTTPS: grep -rn "flushHeaders" . Si hay coincidencias en un manejador HTTPS y alguna ruta devuelve o almacena cuerpos de petición, ponga ese servicio al principio de la cola. Si estaba expuesto a internet, rotar su clave TLS cuesta poco, incluso sin ataques reportados.
4. Si usa 20.x o 25.x, incluya la migración en el tablero de este sprint. Dejarla para el próximo trimestre ya no es una opción.
5. Compruebe que sus orígenes solo aceptan tráfico de su CDN o balanceador.

Nada de esto es un trabajo glamuroso y, siendo sinceros, la actualización en sí suele ser lo fácil. Encontrar el servicio olvidado que termina su propio TLS lleva más tiempo. Si quiere hacerse una idea de cómo abordamos este tipo de auditoría, nuestra descripción de servicios y trabajos anteriores le darán una idea, y nuestro equipo de desarrollo realiza estas actualizaciones de runtime constantemente.

Si le suena un servicio Node con su propia configuración TLS que nadie ha tocado desde el lanzamiento, hablemos.