El proyecto Node.js publicó el 11 de noviembre de 2026 las versiones 26.13.1, 24.22.3 y 22.23.5. Corrigen 16 vulnerabilidades con CVE: siete de severidad alta, seis media y tres baja. La semana pasada, el aviso previo solo decía que habría correcciones de severidad alta, como conté en Node.js 26, 24 y 22 reciben correcciones de seguridad el 11 de noviembre. Ahora los detalles son públicos y muestran con más claridad quién debe actualizar primero.
Dónde están las fallas
Casi todo lo grave está en el servidor HTTP/2 y en la capa TLS del propio Node. Entre las siete altas, según el comunicado:
- un cliente sin autenticación puede tumbar el proceso de un servidor
http2con configuración por defecto, con o sin TLS (CVE-2026-123863), o de un servidor TLS que usaSNICallback, OCSP oserver.addContext()(CVE-2026-126051); - en HTTPS, llamar a
res.flushHeaders()antes de que termine el cuerpo de la petición y luego ares.end()con datos puede hacer que el servidor copie su propia memoria al cuerpo de la petición, lo que puede exponer claves privadas TLS y peticiones de otros usuarios (CVE-2026-123864);node:httpsin TLS no está afectado; - en HTTP/2, el cierre de un stream puede enviar al cliente datos de respuesta de otras conexiones (CVE-2026-123866), y servir archivos con
respondWithFile()abre la puerta a corrupción de memoria (CVE-2026-123874); - un cliente puede mantener sesiones HTTP/2 abiertas para siempre, consumiendo memoria y descriptores de archivo (CVE-2026-123865);
- en servidores con reglas de certificado de cliente distintas por hostname, la renegociación TLS 1.2 permite cambiar de hostname y llevar la autenticación de un host a otro (CVE-2026-123872).
Dos de las fallas medias también afectan la autenticación: un contexto SNI que define solo la CA cae a la CA por defecto y deja pasar clientes que debería rechazar (CVE-2026-123867), y https.Agent puede reutilizar una sesión TLS validada con la lista de certificados por defecto en una petición que pedía una política más estricta (CVE-2026-123877). Otra media escribe la URL del proxy, con usuario y contraseña, en los mensajes de error ERR_PROXY_INVALID_CONFIG, que suelen terminar en logs y herramientas de monitoreo de errores (CVE-2026-123871). Las tres bajas afectan al Permission Model y a zlib.
Las versiones también actualizan dependencias: llhttp en las tres líneas, undici en 24 y 26 y SQLite en 22 y 24.
Quién debe apurarse
El comunicado da las tres líneas con soporte como afectadas. Algunas fallas altas, como CVE-2026-123863 y CVE-2026-123874, solo aplican a 24 y 26. El orden de prioridad que sigue es una evaluación mía, a partir de las condiciones descritas en cada CVE.
Arriba de la lista está quien expone Node directamente a internet y termina TLS o HTTP/2 en el propio proceso: servidores http2 o https nativos, frameworks configurados para servir HTTP/2 y servicios con mTLS (autenticación mutua por certificado) con reglas por hostname. En esos casos, un cliente anónimo puede tumbar el servicio o leer memoria.
Cuando un CDN, balanceador o proxy inverso termina el TLS y habla HTTP/1.1 con Node, la mayoría de las fallas de servidor HTTP/2 y TLS no llega a la aplicación. Quedan las correcciones del lado cliente (https.Agent), la filtración de credenciales de proxy en logs y las actualizaciones de llhttp, que valen para cualquier servidor HTTP. Este grupo también debe actualizar, con menos urgencia.
Node 20 y 25 ya salieron del soporte de seguridad, el 30 de abril y el 1 de junio de 2026, según endoflife.date. El comunicado dice que las versiones sin soporte "siempre están afectadas" cuando sale una versión de seguridad, y no reciben parche. Para quien sigue en ellas, la decisión es de migración, y lo que pesa en ella fue el tema de Una versión con soporte también exige decidir cuándo migrar.
Qué hacer ahora
- Subir a 26.13.1, 24.22.3 o 22.23.5, según la línea en uso. Son parches dentro de la misma línea, sin cambio de versión mayor.
- Reconstruir las imágenes Docker a partir de una etiqueta actualizada. Un contenedor que sigue corriendo mantiene el binario antiguo.
- En plataformas gestionadas que eligen el runtime por ti, confirmar con el proveedor cuándo llega la nueva versión y si el cambio es automático.
- Buscar URL de proxy con credenciales en los logs y en las herramientas de monitoreo de errores y cambiar esas contraseñas si aparecen, porque la corrección evita nuevas filtraciones pero no borra lo que ya quedó registrado.
Para quien está en el primer grupo, yo lo trataría como trabajo de esta semana. El comunicado no fija plazo ni menciona explotación activa.
Lo que todavía no está claro
El comunicado no dice si alguna de las fallas ya se está explotando ni da puntuación CVSS para cada una. Tampoco dice cuándo las imágenes oficiales y los proveedores gestionados entregarán las nuevas versiones. Si alguna entra en el catálogo de vulnerabilidades explotadas de CISA, la prioridad sube también para quien está detrás de un proxy.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
