Node.js corrige 10 vulnerabilidades, entre ellas una falla en Brotli que permite ejecutar código remoto

0 0 votos

Valora la Publicación

Node.js publicó el 21 de octubre actualizaciones de seguridad que corrigen 10 vulnerabilidades en las tres líneas con soporte (22.x, 24.x y 26.x). La más grave, CVE-2026-111497, es una escritura fuera de los límites de memoria en el descompresor Brotli que, según el propio proyecto, permite ejecutar código de forma remota.

Las versiones corregidas son Node.js 22.23.4, 24.22.1 y 26.12.1. Node.js 20 y anteriores ya no tienen soporte y no reciben el arreglo.

Qué es Brotli y por qué una falla ahí es seria

Brotli es un formato de compresión creado por Google. Los navegadores y los servidores lo usan todo el tiempo para achicar lo que viaja por la red: cuando una respuesta HTTP llega con el encabezado Content-Encoding: br, viene comprimida con Brotli y hay que descomprimirla antes de leerla.

Node.js trae Brotli incorporado en su módulo zlib, y lo usan desde el cliente fetch() hasta muchas librerías de servidores web y proxies. Eso significa que el descompresor procesa datos que llegan de afuera: una respuesta de otro servidor, un archivo subido o un pedido de un cliente.

Una escritura fuera de límites (out-of-bounds write) ocurre cuando un programa escribe datos más allá del espacio de memoria que tenía reservado. Con un archivo comprimido armado a propósito, un atacante puede pisar memoria que no debería tocar. En el peor caso eso termina en ejecución remota de código: el atacante consigue que el proceso de Node.js corra instrucciones suyas. En el caso más leve, el proceso se cae.

La falla no es exclusiva de Node.js: está en la librería Brotli de Google, que publicó el mismo 21 de octubre las versiones 1.2.1, 1.1.1 y 1.0.10 con la corrección del mismo CVE. Cualquier otro software que incluya su propia copia de Brotli también tiene que actualizarse.

Las otras nueve fallas

El aviso oficial de Node.js clasifica cuatro fallas como de severidad alta, tres como media y tres como baja. Varias tocan la validación de certificados TLS, el mecanismo que garantiza que una conexión cifrada va al servidor correcto:

Alta, CVE-2026-106069 y CVE-2026-105483: dos formas de saltear la verificación del nombre en el certificado TLS cuando el host es una dirección IP escrita de forma no estándar (por ejemplo, con dígitos de ancho completo). La segunda afecta solo a 24.x y 26.x.
Alta, CVE-2026-105482: dns.resolve corta los nombres que contienen un carácter nulo, lo que permite que una consulta termine apuntando a un dominio distinto del que se pidió.
Media, CVE-2026-106072: con direcciones IPv4 no canónicas, un certificado emitido para un nombre de dominio puede validar una conexión a una IP.
Media, CVE-2026-105481: una conexión keep-alive (la que se reutiliza para varios pedidos) puede procesar una respuesta que llegó antes de que se enviara el pedido.
Media, CVE-2026-106074: en aplicaciones que usan snapshots de arranque o se distribuyen como ejecutable único (SEA), crypto.randomUUID() y randomInt() repiten los mismos valores en cada proceso, porque la reserva de aleatoriedad queda guardada dentro del snapshot.
Baja: un problema en el lector de ZIP de la línea 26.x y dos formas de esquivar el Permission Model, el modo experimental que restringe a qué archivos puede acceder un proceso.

La falla de los valores aleatorios repetidos merece atención aparte: si una aplicación usa randomUUID() para generar identificadores de sesión o tokens, dos instancias arrancadas desde el mismo snapshot producen la misma secuencia, y un atacante que conozca una puede predecir la otra.

También bloquea las CA de eMudhra

Las mismas versiones actualizan el almacén de certificados de Node.js para bloquear las ocho autoridades certificantes intermedias de eMudhra cuyas claves privadas se informaron comprometidas el 20 de octubre. Las CA (autoridades certificantes) son las entidades que firman los certificados TLS; con una clave filtrada, alguien podría emitir certificados válidos para cualquier dominio.

Node.js no consulta por defecto si un certificado fue revocado, así que para un servicio en Node.js este bloqueo llega recién con la actualización. Además se actualizaron dependencias como Undici (el cliente HTTP detrás de fetch()), c-ares, OpenSSL en 22.x y 24.x, y SQLite en 22.x.

Qué hacer

Actualizar Node.js a 22.23.4, 24.22.1 o 26.12.1, según la línea que se use. Verificar con node --version en cada servidor, contenedor y pipeline de CI.
Reconstruir las imágenes de contenedores: una imagen basada en node:22 o node:24 no se actualiza sola; hay que volver a generarla y desplegarla.
Migrar lo que siga en Node.js 20 o anterior: el aviso aclara que las versiones sin soporte siempre quedan afectadas cuando sale una actualización de seguridad.
Revisar otras copias de Brotli: paquetes del sistema operativo, bindings de Python o servidores que la incluyan, a las versiones 1.2.1, 1.1.1 o 1.0.10.
Regenerar snapshots y ejecutables únicos con la versión nueva si la aplicación usa esa forma de distribución.

El aviso no incluye mitigaciones alternativas: la corrección es actualizar.

¿Cuántos Node.js tienen corriendo sin saberlo?

Node.js suele estar en más lugares de los que figuran en el inventario: herramientas internas, funciones serverless, agentes de CI, imágenes viejas que nadie reconstruye. ¿Ya saben qué versión corre en cada uno? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →