Node.js corrige diez fallas, incluidas cuatro de severidad alta en DNS, TLS y Brotli

El proyecto Node.js publicó el 21 de octubre una ronda de seguridad para las ramas 26.x, 24.x y 22.x: las versiones corregidas son 26.12.1, 24.22.1 y 22.23.4. El aviso enumera diez vulnerabilidades de distinta severidad y actualizaciones de componentes como c-ares, OpenSSL, SQLite, Undici y el almacén de certificados. La actualización importa para aplicaciones que ejecutan Node.js directamente y también para imágenes de contenedor, funciones, herramientas y appliances que incluyen su propio runtime.

La falla de mayor severidad descrita en el aviso es CVE-2026-111497, un error de escritura fuera de límites en el decodificador Brotli. Si una aplicación procesa datos comprimidos controlados por un atacante mediante `node:zlib`, el defecto puede corromper memoria y potencialmente causar una caída, exponer memoria o permitir ejecución remota de código. La explotación depende de que exista una ruta alcanzable que descomprima entrada no confiable; no todo proceso Node.js queda automáticamente expuesto.

Entre los fallos de severidad alta también hay errores de verificación de nombres de host TLS. Ciertas representaciones no canónicas de direcciones IPv4 pueden hacer que un certificado se compare contra una dirección distinta de aquella a la que se conectó el cliente, o permitir bajo condiciones específicas que un nombre DNS autentique un extremo IP. Otro defecto hace que las funciones `dns.resolve*()` y `dns.reverse()` trunquen nombres con byte NUL, lo que puede crear una diferencia entre el nombre validado por una aplicación y el nombre consultado.

El paquete incluye asimismo una condición de carrera en conexiones HTTP keep-alive, una falla que puede repetir valores aleatorios en procesos construidos desde ciertos snapshots y problemas de lectura de archivos ZIP y del modelo de permisos. Tienen condiciones y efectos distintos. Por ello, el número de diez correcciones no equivale a diez formas de ejecución remota: hay que revisar la descripción técnica y severidad de cada identificador para priorizar.

El boletín del proyecto cubre Node.js 26.x, 24.x y 22.x. Las instalaciones fuera de soporte pueden seguir afectadas pero no necesariamente reciben un parche oficial; las empresas que dependen de distribuciones de terceros deben confirmar la disponibilidad de su proveedor. Tener una versión corregida en un repositorio no actualiza automáticamente servicios ya desplegados, contenedores activos, funciones publicadas ni ejecutables empaquetados.

La prioridad más alta corresponde a servicios que aceptan contenido no confiable y después lo descomprimen con Brotli, especialmente si el flujo puede alcanzarse desde Internet. Las fallas TLS y DNS requieren atención cuando la aplicación toma destinos de entrada de usuario, aplica listas de permitidos o valida certificados de forma propia. El análisis debe basarse en rutas y configuración reales, no únicamente en que el equipo use Node.js o en la presencia de una dependencia en el inventario.

La fuente primaria del proyecto identifica versiones, causas, componentes y correcciones. Medios especializados reportaron que Microsoft y otros ecosistemas también publicaron actualizaciones por la falla de Brotli compartida; esto amplía los productos que una organización podría necesitar inventariar, pero no modifica el alcance del boletín de Node.js. Cada entorno debe comprobar sus propios runtimes y bibliotecas.

Investigadores divulgaron demostraciones del defecto Brotli, de acuerdo con publicaciones técnicas independientes. El aviso del proyecto no afirma que todos los fallos del lote se estén explotando activamente ni describe una campaña generalizada contra clientes Node.js. La distinción importa: una prueba reproducible puede demostrar que una condición es explotable, pero no identifica por sí sola víctimas, escala o compromiso efectivo. La respuesta inmediata sustentada es actualizar y evaluar exposición.

Actualice a 22.23.4, 24.22.1 o 26.12.1 según la rama utilizada, o a una versión posterior confirmada como corregida por el proyecto. Después reconstruya y despliegue los artefactos derivados, incluyendo imágenes, ejecutables únicos y funciones. Si no puede actualizar de inmediato, reduzca temporalmente la exposición de las rutas que procesan Brotli no confiable cuando el diseño lo permita y asigne responsable y fecha para completar el cambio.

Verifique la versión en ejecución después del despliegue y revise servicios que incorporan una copia de Node.js propia. Para aplicaciones críticas, inspeccione reinicios, errores de proceso y patrones anómalos en el período previo a la corrección. Confirme también que no se conservan instancias antiguas por escalado automático o restauración de imágenes previas. En sistemas con datos sensibles, preserve logs y aplique el proceso de respuesta a incidentes si aparecen señales concretas; la publicación del parche no es evidencia de que un entorno haya sido atacado.