JC Rueda
Ciberseguridad · Aviso

Node.js · Fallos en TLS y Brotli, con posible ejecución de código

El 21 de octubre de 2026, Node.js corrigió diez vulnerabilidades en sus tres ramas con soporte. Las más serias son una escritura fuera de límites en el descompresor Brotli, que puede acabar en ejecución remota de código, y varios fallos en la comprobación de certificados TLS.

Publicado Lectura 9 min Ref. CVE-2026-111497, CVE-2026-105482, CVE-2026-105483, CVE-2026-106069, CVE-2026-105481, CVE-2026-106072, CVE-2026-106074, CVE-2026-106070, CVE-2026-106071, CVE-2026-106073 CVSS —

Resumen

El proyecto Node.js publicó el 21 de octubre de 2026 las versiones de seguridad 22.23.4, 24.22.1 y 26.12.1. Corrigen diez vulnerabilidades: cuatro de severidad alta, tres media y tres baja. La más grave (CVE-2026-111497) está en el descompresor Brotli incluido en Node.js: con datos comprimidos manipulados se puede corromper la memoria del proceso, y en el peor caso ejecutar código. Otras tres permiten, en ciertos casos, que la comprobación de certificados TLS dé por buena una conexión con un servidor que no debería. No consta explotación activa y no hay puntuación CVSS oficial.

Materias: vulnerabilidades, parches, Node.js, TLS, ejecución remota de código, corrupción de memoria, desarrollo de software

Node.js, el entorno que ejecuta JavaScript fuera del navegador y sobre el que funcionan gran parte de las API, webs y herramientas internas de empresas y administraciones, ha publicado una tanda de parches de seguridad para sus ramas 22, 24 y 26. El fallo más llamativo está en la pieza que descomprime datos en formato Brotli: un fichero o respuesta manipulados pueden corromper la memoria del proceso. Hay además varios errores en la verificación de certificados TLS, el mecanismo que garantiza que hablamos con el servidor correcto. Hoy no hay constancia de ataques reales, pero el parche ya está publicado y conviene aplicarlo cuanto antes.

Descripción

Qué es y a quién afecta

Node.js es un runtime (entorno de ejecución): el programa que permite ejecutar código JavaScript en servidores, contenedores y equipos de desarrollo. Si una organización tiene una API, una web o una herramienta de integración continua escrita en JavaScript o TypeScript, es muy probable que dependa de Node.js, aunque nadie lo haya instalado a mano porque viene dentro de una imagen de contenedor.

El 21 de octubre de 2026, el proyecto publicó un aviso de seguridad conjunto. Corrige diez vulnerabilidades con identificador CVE (el código público que se asigna a cada fallo):

  • Severidad alta:
    • CVE-2026-111497: escritura fuera de límites en el descompresor Brotli. Afecta a 22.x, 24.x y 26.x.
    • CVE-2026-105483: verificación del nombre de host TLS burlada con IP escritas en dígitos de ancho completo (１２７.0.0.1). Afecta a 24.x y 26.x. Es una regresión, es decir, un fallo que reapareció tras la corrección de CVE-2026-48618.
    • CVE-2026-106069: verificación del nombre de host TLS burlada con IPv4 que empiezan por cero (0127.0.0.1). Afecta a 22.x, 24.x y 26.x.
    • CVE-2026-105482: dns.resolve*() y dns.reverse() recortan los nombres que contienen el carácter nulo (NUL). Afecta a 22.x, 24.x y 26.x. Completa una corrección anterior que había quedado incompleta (CVE-2026-48930).
  • Severidad media:
    • CVE-2026-105481: un socket keep-alive (conexión HTTP reutilizada) acepta una respuesta que llegó antes de enviar la petición.
    • CVE-2026-106072: certificados con nombres DNS sirven para autenticar direcciones IPv4 escritas de forma no canónica (0177.0.0.1, 127.1).
    • CVE-2026-106074: crypto.randomUUID() y randomInt() pueden repetir valores entre procesos distintos que arrancan desde la misma snapshot (imagen de arranque precalculada) o desde el mismo ejecutable autónomo (SEA, Single Executable Application).
    Las tres afectan a 22.x, 24.x y 26.x.
  • Severidad baja:
    • CVE-2026-106070: zlib.ZipFile devuelve bytes controlados por el atacante tras una cabecera ZIP inválida. Solo 26.x.
    • CVE-2026-106071: en el modelo de permisos, un comodín como --allow-fs-read=/etc/passwd.* también da acceso a /etc/passwd. Solo 26.x.
    • CVE-2026-106073: fs.realpathSync() se salta los controles de lectura del modelo de permisos. Afecta a las tres ramas.

Versiones afectadas: todas las de las ramas 22.x, 24.x y 26.x anteriores a 22.23.4, 24.22.1 y 26.12.1. El proyecto recuerda que las ramas que ya no tienen soporte (end-of-life: 18.x, 20.x, 23.x, 25.x…) deben darse por afectadas y no recibirán parche.

La severidad es la que asigna el propio proyecto Node.js. No ha publicado puntuación CVSS (la escala estándar de 0 a 10) y no hemos podido verificar una en la base de datos NVD del NIST. Tampoco indica la categoría CWE (la clasificación común de tipos de fallo). Por su naturaleza, el fallo de Brotli encaja en CWE-787 (escritura fuera de límites) y los de TLS en CWE-295 (validación incorrecta de certificados), pero se trata de una clasificación nuestra, no oficial.

Mecánica

El fallo de Brotli (CVE-2026-111497)

Brotli es un formato de compresión muy usado en la web: muchos servidores envían sus páginas y respuestas comprimidas con él (cabecera HTTP Content-Encoding: br). Node.js lleva su propia copia del descompresor, a la que se accede desde el módulo node:zlib.

Según el aviso oficial, cuando el flujo comprimido contenía un «cambio de bloque» inválido, el descompresor no lo trataba como un error definitivo. Lo interpretaba como «faltan datos, espera a que lleguen más» y seguía añadiendo bytes a un búfer interno de solo ocho bytes, escribiendo más allá de su final. Eso es una escritura fuera de límites, un tipo de corrupción de memoria. El commit que lo corrige (0ed4268a4401) se incorporó a Node.js desde el proyecto Brotli.

Requisito para el ataque: que la aplicación descomprima con node:zlib datos Brotli que el atacante pueda controlar. Por ejemplo, ficheros subidos por usuarios, peticiones con cuerpo comprimido o respuestas de servidores de terceros. La firma OX Security señala que la descompresión automática de respuestas HTTP comprimidas con Brotli también pasa por este código, de modo que un cliente que consulte un servidor malicioso o comprometido podría quedar expuesto. El aviso oficial no lo detalla expresamente.

Impacto según el fabricante: caída del proceso, revelación de memoria o ejecución remota de código. Es importante matizar que se trata del peor escenario posible. No se ha publicado ninguna prueba de concepto verificada ni consta que se haya logrado ejecutar código en la práctica. OX Security advierte, de hecho, contra supuestos exploits y «scripts de parche» no verificados que circulan sobre este fallo.

Los fallos de verificación TLS

TLS es el protocolo que cifra las conexiones (el «candado» de HTTPS). Además de cifrar, comprueba que el certificado del servidor corresponde al nombre o a la IP a la que nos conectamos. Esa comprobación la hace tls.checkServerIdentity(), y estos tres fallos la engañan con direcciones IP escritas de forma poco habitual:

  • CVE-2026-106069: Node.js interpreta 0127.0.0.1 como octal (87.0.0.1) al comprobar el certificado, pero el sistema operativo (en macOS, por ejemplo) lo resuelve como decimal (127.0.0.1) al conectar. El certificado se valida contra una IP y la conexión va a otra.
  • CVE-2026-105483: con dígitos de ancho completo (１２７.0.0.1), Node.js no reconocía la dirección como una IP y la comparaba con los nombres DNS del certificado. Así, un certificado con DNS:*.0.0.1 podía servir para una IP para la que no fue emitido.
  • CVE-2026-106072: algo parecido con formas no canónicas como 127.1.

En la práctica, estos ataques requieren que el atacante influya en la dirección a la que se conecta la aplicación (por ejemplo, una URL configurable o suministrada por el usuario) y que además controle un servidor con un certificado adecuado. Son escenarios acotados, pero socavan precisamente la garantía de identidad que ofrece TLS.

Resto de correcciones

El fallo de dns con el carácter NUL puede hacer que se resuelva un nombre distinto del que la aplicación cree haber validado. El de keep-alive permite que una respuesta HTTP «adelantada» se asigne a una petición posterior. El de randomUUID() puede generar identificadores repetidos en despliegues basados en snapshots o SEA, lo que es relevante si esos valores se usan como identificadores únicos o tokens. Los fallos del modelo de permisos (la función experimental que restringe a qué ficheros puede acceder un proceso) solo importan a quien la use como barrera de seguridad.

Respuesta del creador

Respuesta del proyecto Node.js

El proyecto publicó el 21 de octubre de 2026 su aviso «Wednesday, October 21, 2026 Security Releases» y, el mismo día, las versiones corregidas de las tres ramas con soporte. Fue un proceso coordinado: los fallos se comunicaron de forma privada siguiendo la política de seguridad del proyecto, y el aviso reconoce a quienes los descubrieron. El de Brotli lo comunicaron Khai Tran y Sylvie Mayer (OpenAI Codex Security). Varios de los de TLS y DNS, Hasan Flayyih Abdullah y otros investigadores. El aviso no propone soluciones provisionales: la única medida oficial es actualizar.

Además de las correcciones propias, las versiones incluyen dependencias actualizadas:

  • c-ares 1.34.9 y Undici (el cliente HTTP que usa fetch()) en las tres ramas.
  • OpenSSL 3.5.9 en 22.x y 24.x.
  • SQLite 3.53.4 en 22.x.
  • Los certificados raíz de confianza (NSS 3.131.1), actualizados por el compromiso de una CA intermedia de eMudhra.

Autoridades y explotación

A 28 de octubre de 2026 no consta que ninguno de estos CVE figure en el catálogo KEV de la CISA (la lista estadounidense de vulnerabilidades explotadas). Ni el fabricante ni las fuentes consultadas informan de explotación activa. No hemos localizado un aviso específico de INCIBE-CERT. Las noticias y análisis publicados (Hispasec, OX Security, SOC Prime) se basan en el aviso oficial y no aportan pruebas de ataques reales.

Parches y mitigaciones

Versiones corregidas

  • Rama 22.x (LTS): actualizar a 22.23.4 o posterior.
  • Rama 24.x (LTS): actualizar a 24.22.1 o posterior.
  • Rama 26.x (Current): actualizar a 26.12.1 o posterior.
  • Ramas sin soporte (18.x, 20.x, 23.x, 25.x y anteriores): no habrá parche. La única salida es migrar a una rama mantenida según el calendario oficial de versiones.

Qué hacer ya

  1. Inventariar dónde se ejecuta Node.js: servidores, imágenes de contenedor, funciones serverless, ejecutores de CI/CD, aplicaciones Electron y ejecutables SEA. La versión se comprueba con node --version.
  2. Priorizar los servicios expuestos a Internet y los que descomprimen Brotli de origen externo, ya sea directamente con zlib o al consumir respuestas HTTP comprimidas de terceros. Después, los que abren conexiones TLS a direcciones IP que puede suministrar un usuario.
  3. Actualizar y reconstruir las imágenes de contenedor con la versión corregida, y volver a desplegarlas. Actualizar el sistema base no basta si Node.js va empaquetado en la imagen.
  4. Si se compila Node.js o se usa un paquete de distribución enlazado contra una biblioteca Brotli del sistema (opción --shared-brotli), hay que comprobar que esa biblioteca incluye la corrección del proyecto Brotli. Algunos medios lo apuntan, aunque el aviso oficial no lo menciona.
  5. Mientras no sea posible actualizar (medida prudente, no oficial): evitar descomprimir Brotli de origen no confiable, desactivar la aceptación de Content-Encoding: br donde sea viable y validar que las direcciones IP suministradas por usuarios estén en formato canónico antes de conectar por TLS.
  6. Validar en preproducción los flujos TLS y DNS si se usan configuraciones poco habituales. Las correcciones rechazan ahora IP no canónicas, lo que podría romper integraciones que dependían de ellas.
  7. Desconfiar de supuestos exploits o «scripts de parche» de terceros: la corrección es la versión oficial.

Para organizaciones sujetas a NIS2, al Esquema Nacional de Seguridad o al RGPD (art. 32, seguridad del tratamiento), conviene dejar constancia documental de cuándo se evaluó y se aplicó el parche. Es la prueba de diligencia debida si más adelante hay un incidente.

Fuentes