Ir al contenido

El medio de los artesanos de la web viernes, 13 de noviembre de 2026

MailStudio
Seguridad

Node.js corrige 16 fallos de seguridad en las ramas 22, 24 y 26

Node.js publicó el 11 de noviembre de 2026 parches para dieciséis vulnerabilidades, nueve de severidad alta, concentradas en HTTP/2 y TLS. Se recomienda actualizar sin demora a 22.23.5, 24.22.3 o 26.13.1.

El proyecto Node.js publicó el 11 de noviembre de 2026 una tanda de parches de seguridad para las tres ramas activas: 22.x, 24.x y 26.x. Se corrigen dieciséis vulnerabilidades, nueve de ellas de severidad alta, la mayoría alojadas en el módulo HTTP/2 y en la capa TLS. Se recomienda actualizar sin demora a las versiones 22.23.5, 24.22.3 o 26.13.1 en cualquier servidor expuesto a clientes no autenticados.

Dieciséis fallos corregidos, un volumen inusual

La publicación agrupa correcciones repartidas en tres niveles de severidad: nueve altas, seis medias y una baja. Varias habilitan escenarios de denegación de servicio o fuga de memoria que pueden activarse de forma remota, sin autenticación previa. Dos de ellas son variantes o correcciones incompletas de fallos ya tratados en el pasado, una señal de lo difícil que resulta cerrar del todo ciertas clases de errores en la implementación HTTP/2 del runtime, apenas un mes después de que Node.js 26 entrara en soporte a largo plazo bajo el nombre Lithium.

HTTP/2 y TLS concentran los puntos críticos

Siete de los dieciséis parches afectan directamente al módulo HTTP/2: uso de memoria ya liberada durante el cierre de un flujo, un desbordamiento de un byte en session.altsvc(), o sesiones que quedan atascadas en CLOSE_WAIT por falta de limpieza tras un error de protocolo. En el lado TLS, una reentrada de llhttp_execute() provocada por una escritura de longitud cero puede causar uso de memoria liberada y exponer cuerpos de solicitudes en curso. Otro fallo permite a un cliente cambiar el nombre de servidor durante una renegociación TLS 1.2, saltándose políticas de certificado de cliente definidas por host.

CVESeveridadComponenteRamas afectadas
CVE-2026-123864AltaHTTPS / llhttp22.x, 24.x, 26.x
CVE-2026-123866AltaHTTP/222.x, 24.x, 26.x
CVE-2026-123872AltaTLS22.x, 24.x, 26.x
CVE-2026-126051AltaTLS24.x, 26.x
CVE-2026-123871MediaProxy22.x, 24.x, 26.x
CVE-2026-106071BajaModelo de permisos22.x, 24.x, 26.x

El modelo de permisos dejaba pasar comodines demasiado amplios

El fallo CVE-2026-106071 afecta a las aplicaciones lanzadas con el modelo de permisos experimental. Una regla en apariencia restrictiva puede en realidad autorizar mucho más de lo previsto:

# Pensada para coincidir solo con archivos /etc/passwd.,
# pero también permite leer /etc/passwd directamente
node --permission --allow-fs-read=/etc/passwd.* app.js

El parche ajusta la interpretación de los patrones comodín para las opciones --allow-fs-read y --allow-fs-write. Los equipos que se apoyan en este modelo para aislar procesos deben revisar sus reglas existentes tras actualizar.

Nueve de las dieciséis vulnerabilidades corregidas llevan la severidad más alta que Node.js asigna fuera de un fallo crítico, un volumen inusual para una sola tanda de parches.

Las versiones que ya llegaron a su fin de vida no reciben ningún parche: una aplicación que siga corriendo sobre una rama de Node.js sin mantenimiento queda expuesta a todos estos fallos, HTTP/2 y TLS incluidos.

Priorizar la actualización según la exposición real

No todos los fallos pesan igual según la arquitectura en producción. Los problemas de HTTP/2 importan sobre todo a los servidores que aceptan ese protocolo desde clientes no controlados. Los fallos ligados a respondWithFile() solo afectan a las aplicaciones que sirven archivos por esa vía. El problema de zlib solo se dispara si se llama a deflate.params() en pleno flujo. El equipo de Node.js recomienda subir con prioridad a 22.23.5, 24.22.3 o 26.13.1 según la rama en uso, y después auditar las dependencias llhttp y undici, también actualizadas en esta tanda.

Lo que hay que recordar

Se corrigen dieciséis vulnerabilidades en las ramas 22.x, 24.x y 26.x de Node.js, nueve de severidad alta y concentradas en HTTP/2 y TLS. Actualizar a 22.23.5, 24.22.3 o 26.13.1 debería ser prioritario para cualquier servicio expuesto a clientes no autenticados, y los equipos que usan el modelo de permisos deben revalidar sus reglas de filtrado de archivos.

El número de fallos ligados a HTTP/2 en esta tanda no tiene nada de accidental: varios son variantes de errores ya señalados, lo que muestra la complejidad de esta implementación. En mi propia infraestructura prefiero no exponer Node.js directamente y colocar delante un proxy inverso que gestione HTTP/2 y solo reenvíe HTTP/1.1 internamente, una capa de simplicidad que reduce mecánicamente la superficie de ataque, mientras estos parches sucesivos terminan de estabilizar el módulo de verdad. — Simon Janvier

Para profundizar: el detalle completo de las dieciséis vulnerabilidades está publicado en el blog oficial de seguridad de Node.js.

Compartir LinkedIn Bluesky Hacker News E-mail

Leer también