10 vulnerabilidades CVE de Node.js, una vulnerabilidad de ejecución remota de código (RCE) en Brotli y qué hacer si tu versión ha llegado al final de su vida útil (EOL)

La versión resumida

Ir a la versión completa ↓

Qué ocurrió: El 21 de octubre de 2026, Node.js publicó actualizaciones de seguridad para sus tres ramas en soporte, 22.x, 24.x y 26.x, una semana después de una alerta previa. Diez CVE, cuatro de ellas con nivel de riesgo «Alto». Ir a esta sección →

Qué provoca la vulnerabilidad más grave: CVE-2026-111497 es una escritura fuera de límites en el decodificador Brotli que viene integrado en Node.js, y el aviso indica que permite la ejecución remota de código. Cualquier proceso en una versión sin parchear que descomprima datos Brotli controlados por un atacante queda expuesto, y no es necesario que tu código llame directamente a Brotli para que eso ocurra. Ir a esta sección →

¿Cómo de grave es realmente?: La primera demostración pública de concepto solo logró ejecutar código en una versión deliberadamente debilitada, lo que hizo que el problema pareciera menos urgente de lo que sugería el texto del aviso. Posteriormente, el equipo rojo de Imperva publicó Node2Shell, en el que se muestra la ejecución de código en la imagen oficial de Node.js 24.22.0 a través de fetch() y el análisis de solicitudes Express 5. A fecha de 22 de octubre, no se ha informado de ningún caso de explotación en la red. Ir a esta sección →

Quiénes se ven afectados: cualquier versión 22.x, 24.x o 26.x anterior a la versión corregida de su línea, además de las líneas que han llegado al final de su ciclo de vida y para las que Node.js ya no ofrece parches. La tabla de CVE que aparece más abajo muestra qué CVE afectan a cada línea. El aviso reitera su advertencia habitual de que las versiones fuera de soporte siempre se ven afectadas, y que Node.js 20, 18, 16, 14 y 12 no reciben ninguna actualización del desarrollador original. Ir a esta sección →

Situación actual: Ya se han publicado correcciones en el código fuente para las versiones 22, 24 y 26. El WAF de Vercel bloquea la vía de ataque entrante para los proyectos de su plataforma, pero no cubre las respuestas que tu código obtiene de otras fuentes. Se espera que, en las próximas 24 a 48 horas, estén disponibles las compilaciones de ELS for Runtimes para las líneas afectadas que han llegado al final de su ciclo de vida.

Qué hay que hacer hoy: aplicar los parches a las líneas compatibles, trasladar las que han llegado al final de su ciclo de vida a una versión fija de ELS tan pronto como esté disponible la correspondiente a tu línea, y reiniciar todo, ya que un proceso en ejecución mantiene el decodificador antiguo en la memoria. Para ver qué se está ejecutando en este momento:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Ir a esta sección →

La mayor parte del trabajo de seguridad de Node.js se lleva a cabo un nivel por encima. Dependabot abre una solicitud de incorporación de cambios, npm audit Todo queda en silencio y nadie se para a pensar ni un segundo en el código binario sobre el que funciona todo. Sin embargo, el entorno de ejecución tiene sus propios CVE y, el 21 de octubre, se descubrió que el más grave de ellos era una corrupción de memoria en un decodificador al que tu aplicación podría estar enviando datos directamente desde Internet.

Los días 22, 24 o 26, la corrección es aburrida. Actualiza la versión del parche, renueva la flota y sigue adelante.

La cosa se vuelve mucho menos aburrida cuando parte del entorno sigue funcionando con Node.js 18 o 20, ya sea porque un complemento nativo no se puede compilar en versiones más recientes o porque la migración del marco de trabajo se va retrasando trimestre tras trimestre. Esas líneas de código incluyen un decodificador Brotli anterior a la corrección y no reciben ninguno de los parches. La mayor parte de esta entrada trata sobre esa brecha.

El proyecto dio su aviso habitual con una semana de antelación. El 14 de octubre, Antoine du Hamel publicó una prealerta en la lista oss-security indicando que las nuevas versiones 22, 24 y 26 se lanzarían el 21 de octubre o poco después, y que el nivel de gravedad más alto era «Alto». No se mencionaron nombres de componentes ni números CVE, lo cual es habitual en Node.js. Las versiones se lanzaron según lo previsto.

El titular es «CVE-2026-111497». El aviso atribuye el hallazgo a Khai Tran y Sylvie Mayer, de OpenAI Codex Security, y la corrección a Matteo Collina y Antoine du Hamel. Algunas de las primeras noticias afirmaban que Collina había descubierto el fallo, pero el aviso lo sitúa entre los responsables de la corrección. El parche en sí es una selección del commit 0ed4268a de Brotli, que incluye el mensaje, bastante discreto, «Detectar y notificar antes los flujos no válidos».

El momento en que se realizó esa confirmación resulta extraño. Según The Hacker News, el cambio se incorporó por primera vez al código fuente de Brotli en febrero de 2026, pero no se incluyó en una versión de seguridad hasta el 21 de octubre, cuando se lanzaron Brotli 1.2.1, 1.1.1 y 1.0.10. Así pues, una corrección para un error de seguridad de memoria permaneció en un repositorio público durante meses, y el mérito del hallazgo se le atribuye a una herramienta de seguridad basada en IA. Es de esperar que veamos esta combinación con mucha más frecuencia, y que el tiempo que transcurre entre una confirmación no anunciada en el código fuente y un exploit funcional siga reduciéndose.

Las otras tres vulnerabilidades de alta gravedad están relacionadas con el manejo de nombres. CVE-2026-106069 permite que un certificado TLS supere la verificación del nombre de host cuando este solo se resuelve de forma aproximada a una dirección IP. CVE-2026-105483 es una vulnerabilidad independiente que se produce cuando la dirección IP se escribe con dígitos de ancho completo. Esta solo afecta a las versiones 24.x y 26.x, y The Hacker News señala que la confirmación que la corrige describe el fallo como de baja gravedad y difícil de explotar, aunque el aviso lo califica como de alta gravedad. CVE-2026-105482 se encuentra en dns.resolve(), donde un nombre que contuviera un byte NUL podía quedar truncado, por lo que el nombre que tu código validaba y el nombre que realmente se consultaba no eran el mismo. Las versiones corregidas rechazan directamente los bytes NUL en la entrada del resolutor.

Los elementos de nivel medio y bajo son menos relevantes, pero no por ello irrelevantes. Uno que merece la pena destacar para cualquiera que distribuya CLI o herramientas como aplicaciones ejecutables independientes es el CVE-2026-106074. Las cachés de entropía detrás de crypto.randomUUID() y crypto.randomInt() se guardaban en instantáneas de inicio y en los SEA, por lo que cada proceso iniciado desde el mismo binario generaba los mismos valores «aleatorios». Cualquier cosa que utilice esos UUID como tokens o nonces merece ser revisada.

Las versiones también actualizan c-ares, undici y los certificados CA incluidos en las tres líneas, OpenSSL en las versiones 22.x y 24.x, y SQLite en la versión 22.x. El cambio en los certificados es lo más sorprendente. Node.js utiliza la lista raíz de Mozilla, pero no realiza comprobaciones de revocación de forma predeterminada, por lo que las cadenas basadas en los ocho certificados intermedios de eMudhra que se han señalado como comprometidos este mes seguían verificándose correctamente hasta esta versión. Las versiones parcheadas añaden una lista de bloqueo compilada con esas claves, los mismos hash que Go incluyó en su propio parche. Hay que tener en cuenta dos salvedades: las sesiones TLS reanudadas desde antes de la actualización no se vuelven a verificar hasta que expiran, y las líneas al final de su ciclo de vida no reciben el bloqueo en absoluto.

Node.js no descodifica Brotli por sí solo. Algún elemento de tu proceso tiene que solicitarlo, y hay muchas cosas que lo hacen sin que te des cuenta.

El tráfico saliente es el más importante. La función integrada fetch() descomprime las respuestas que contienen Content-Encoding: br de forma automática, y no hay ninguna opción para el usuario que permita desactivarlo. Las versiones actuales de axios, node-fetch y got hacen lo mismo por defecto. Así pues, cualquier servicio que solicite URL que no controle se ve afectado: un emisor de webhooks, un proceso de vista previa de enlaces, un rastreador o un agente de IA que extraiga páginas web para introducirlas en una línea de comandos. Vercel’s boletín añade otra posibilidad que pasa fácilmente desapercibida. Next.js autohospedado no bloquea las respuestas Brotli en la optimización de imágenes, por lo que la solución pasa por actualizar Node.js, sin modificar la configuración de Next.js.

El «inbound» es la segunda vía. Los analizadores de cuerpo de Express 5, a través de body-parser 2.x, descomprimen los cuerpos de las solicitudes en formato Brotli de forma predeterminada, por lo que una API que utilice express.json() descomprimirá un cuerpo Brotli que nunca ha solicitado. El analizador de cuerpos 1.x de Express 4 no admite cuerpos Brotli y los rechaza con un código de error 415. Un simple http El servidor no descodifica los cuerpos de las solicitudes con solo recibirlos. Luego está la vía directa, en la que el código llama a zlib.brotliDecompress() o createBrotliDecompress() en archivos subidos, archivados o almacenados en caché.

Una forma rápida de clasificar la urgencia. Cualquier aplicación conectada a Internet que utilice Express 5, o cualquier aplicación que recupere URL arbitrarias, debe actualizarse hoy mismo. Un servicio de Express 4 que solo se comunique con backends de tu propiedad, sin middleware de descompresión personalizado y sin conexión directa zlib Brotli recurre a datos externos, por lo que puede situarse un poco más abajo en la lista. Aún así, es necesario actualizarlo esta semana, ya que las otras nueve vulnerabilidades (CVE) no dependen de la versión de Express que se utilice. El aviso no ofrece ninguna solución provisional. Configuración inflate: false sobre los analizadores de cuerpo de mensaje, desactivar la descompresión en Axios o Got, o rechazar Content-Encoding: br en el proxy puede reducir la exposición durante unas horas, pero fetch() no tiene botón de apagado y ninguna de esas medidas supone una solución.

La historia sobre la gravedad del fallo se desarrolló rápidamente. El 22 de octubre apareció una prueba de concepto pública y, según The Hacker News, solo se logró la ejecución de código en una versión de prueba debilitada deliberadamente. En una versión estándar, su autor informó de un fallo del sistema y una lectura limitada de memoria. Habría sido fácil leer eso y posponer el ticket para el siguiente sprint.

Ese mismo día, el equipo rojo de Imperva publicó Node2Shell. En contenedores nuevos que ejecutaban la imagen oficial de Node.js 24.22.0 para Linux arm64, sin depurador ni binario instrumentado, los datos Brotli enviados como respuesta a una solicitud o como cuerpo de una solicitud hacían que la aplicación ejecutara el código incluido en dichos datos. Lo reprodujeron a través de fetch() y en las versiones de Express 5.0.0 a 5.3.0 con el raw() y json() analizadores sintácticos. Las mismas entradas se rechazaron en la dirección 24.22.1. Hicieron falta varios intentos para configurarlo, y solo lo probaron en arm64, así que no es algo que se haga con solo pulsar un botón, pero está muy lejos de ser «algo que solo funciona en un laboratorio».

Si el equipo de triaje ha archivado este caso basándose en la primera prueba de concepto, reábrelo. Imperva también señala que las salidas inesperadas de procesos durante la descompresión pueden ayudar a priorizar la investigación, aunque ni los bloqueos ni los errores del decodificador son, por sí solos, un indicio fiable de explotación. A fecha de 22 de octubre, no se ha notificado ningún caso de explotación en el mundo real, y CVE-2026-111497 no figura en el catálogo de vulnerabilidades explotadas conocidas de la CISA.

Las líneas de la parte superior no se tocan

Los avisos de seguridad de Node.js incluyen una advertencia permanente, y este la reitera. Las versiones fuera de ciclo de vida siempre se ven afectadas cuando se publica una actualización de seguridad. Se trata de una declaración de política, no de un resultado de prueba específico por CVE. Lo que sí es seguro es que la corrección de Brotli no se incorporó a Node.js hasta el 21 de octubre, por lo que ninguna versión fuera de ciclo de vida del código fuente la incluye. Node.js 20 alcanzó el fin de vida útil el 30 de abril de 2026, la versión 18 el 30 de abril de 2025, la 16 el 11 de septiembre de 2023, la 14 el 30 de abril de 2023 y la 12 el 30 de abril de 2022. Ninguna de ellas recibirá una versión para esto. Vercel también se ha mostrado muy claro al respecto. Los proyectos de su plataforma que sigan fijados en Node.js 20 tendrán que cambiar a la versión 22 o 24 y volver a implementarlos, ya que la versión 20 no recibirá la corrección.

¿Desde cuándo existe el fallo de Brotli? Brotli se incluye en Node.js desde las versiones 10.x y 11.x, y el proyecto Brotli ha aplicado esta corrección hasta la rama 1.0. Esto es un claro indicio de que la lógica del decodificador vulnerable es antigua, y no algo introducido la pasada primavera. Node.js 16 y versiones anteriores no tienen una variable global fetch(), pero Axios y Got siguen procesando las respuestas Brotli con el mismo decodificador zlib, y directamente zlib Las llamadas funcionan igual en todas las líneas.

Las instalaciones que causan problemas rara vez son las que cualquiera consideraría servidores de Node.js. Un contenedor de compilación fijado en Node 16 porque un complemento de procesamiento de imágenes dejó de compilarse en la versión 18. Una herramienta de administración interna que alguien distribuyó como un único binario en 2022. Un dispositivo de un proveedor con Node 14 en su consola web. Imagínate un equipo de pagos con 40 servicios en Node 18, bloqueados allí por una dependencia cuyo mantenedor ya no está, leyendo un aviso de RCE sin ningún parche adjunto. Nadie va a migrar 40 servicios antes del viernes.

Esa es la brecha que cubre ELS for Runtimes. TuxCare proporciona correcciones de seguridad para las versiones de Node.js que han llegado al final de su ciclo de vida, de modo que, una vez que se lanza la versión de su línea, un servicio fijado en la versión 18 recibe las correcciones de este mes como una actualización del paquete, en lugar de tener que realizar una migración de emergencia. La migración sigue siendo necesaria, y las fechas de fin de vida útil de Node.js no van a cambiar. Con ELS, la migración se lleva a cabo según el calendario que elija tu equipo, no según el que te imponga un aviso de seguridad.

La documentación de ELS para Runtimes enumera las versiones de Node.js 12 a 26 por sistema operativo; hay otras versiones y arquitecturas disponibles previa solicitud. Para obtener más información sobre cómo seguir utilizando la versión más allá de su fin de vida útil, consulta esta guía sobre el soporte ampliado de Node.js tras el fin de vida útil.

Esto es lo que figura actualmente en la documentación en el apartado de soporte activo:

Hay versiones disponibles para x86_64 en todos los sistemas operativos compatibles, y para aarch64 (arm64) en Debian 12, Debian 13 y Alpine 3.23 y versiones posteriores. Las versiones para arm64 cobran especial relevancia esta semana, ya que la demostración de ejecución de código de Imperva se ejecutó en arm64.

Los paquetes de distribución funcionan de forma ligeramente diferente. Algunas versiones, como los paquetes de Debian y Ubuntu y Homebrew, enlazan con una biblioteca Brotli compartida en lugar de con la copia incluida en Node.js. En ese caso, mantente al tanto de las actualizaciones de seguridad de la biblioteca Brotli que te proporciona tu gestor de paquetes. Para comprobarlo, basta con una sola línea:

ldd "$(command -v node)" | grep -i brotli

Si en la salida aparece «libbrotli path», significa que el binario enlaza con una biblioteca Brotli compartida. Si no aparece nada, es probable que se trate de una copia integrada o enlazada estáticamente, que es como se distribuyen las compilaciones oficiales de nodejs.org; sin embargo, el comando por sí solo no puede demostrarlo, así que comprueba la información del paquete o la configuración de la compilación si te interesa. ldd es solo para Linux. En macOS, donde se ejecuta Homebrew, otool -L "$(command -v node)" | grep -i brotli hace lo mismo.

Consigue hoy mismo ELS para Runtimes →

Empieza por el inventario, porque la lista siempre es más larga de lo que uno espera. Los gestores de versiones como nvm y Volta guardan los binarios en los directorios de usuario, mientras que los paquetes de distribución los guardan en /usr/bin, y ELS se compila en tiempo real en /opt/alt/ con un script de activación para cada versión. Estos dos bucles de Bash muestran cada node en tu PATH actual, entonces todas las compilaciones de ELS que se encuentren en /opt/alt/, junto con la versión que indica cada uno:

type -ap node | while read -r n; do echo "$n $("$n" -v)"; done
for e in /opt/alt/alt-nodejs*/enable; do [ -f "$e" ] && ( . "$e" && echo "$e $(node -v)" ); done

Esto te proporciona un inventario inicial, que no coincide con lo que ejecuta cada servicio. Las unidades de systemd, las configuraciones de PM2, los ejecutores de CI y las imágenes base de los contenedores pueden apuntar cada una a un binario diferente, así que comprueba también esos elementos. En los sistemas basados en RPM, las compilaciones de ELS se actualizan con yum update 'alt-nodejs*', y las instrucciones sobre DEB y APK se encuentran en la misma página de documentación.

No te fíes de las cadenas de versión de la corrección de Brotli en las compilaciones de origen. Node.js ha seleccionado selectivamente el parche sin aumentar la versión de Brotli, por lo que process.versions.brotli Parece idéntico antes y después. La versión sí que reveló una nueva constante de zlib que tienen los binarios modificados y que no tienen los que no lo están:

node -p "'BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH' in require('zlib').constants"

true significa que el decodificador fijo está presente. Esa comprobación solo es fiable para las compilaciones oficiales del desarrollador original; por lo tanto, para las compilaciones de distribución o ELS, sigue las recomendaciones del proveedor. El propio proyecto npx is-my-node-vulnerable También resulta útil para las instalaciones de origen, pero se basa en los números de versión, por lo que una compilación adaptada a versiones anteriores puede parecer vulnerable cuando en realidad no lo es.

A continuación, reinicia el sistema, que es el paso que se omite. Un proceso de Node.js en ejecución conserva el decodificador antiguo hasta que se cierra, y un contenedor lo conserva hasta que se vuelve a implementar a partir de una imagen reconstruida sobre una base parcheada. Los SEA y las instantáneas de inicio deben reconstruirse con el entorno de ejecución parcheado, y en el caso de CVE-2026-106074, esa reconstrucción constituye la corrección. Vuelve a ejecutar el ps utiliza el comando que aparece al principio de esta publicación y comprueba todos los procesos de Node.js que se hayan iniciado tras la aplicación de la actualización. Las aplicaciones con un único ejecutable y los binarios renombrados no aparecerán en ese patrón, así que compruébalos por el nombre del servicio.

Por último, no cierres el ticket basándote en la comparación de versiones realizada por un escáner. Una compilación adaptada a una versión anterior puede seguir indicando su versión original de origen. Si tus herramientas lo permiten, introdúceles los datos de seguridad legibles por máquina de TuxCare para Node.js —que incluyen los avisos CSAF— y mantén un registro del paquete instalado, el aviso al que da respuesta y el proceso que realmente gestiona el tráfico. Eso es lo que te pedirá un auditor.

Por qué un fallo en tiempo de ejecución tiene consecuencias diferentes

Un entorno de ejecución también es una dependencia, y una vez que ya nadie lanza parches para él, cada nueva vulnerabilidad del núcleo permanece sin solucionar mientras ese entorno de ejecución siga en producción. Equipos que nunca lanzarían una versión de Lodash con dos años de antigüedad ejecutan sin problemas su código en una versión de Node.js que dejó de recibir parches de seguridad en 2025.

Esta semana también ha puesto de manifiesto lo poco tiempo que hay para planificar. Siete días desde la prealerta hasta el lanzamiento, una demostración pública del concepto al día siguiente, un exploit operativo contra la imagen de serie ese mismo día y correcciones que llegan exactamente a tres versiones. «Actualizar el próximo trimestre» es un plan perfectamente válido para el próximo trimestre. Pero no es ningún plan para esta semana.

Así que aplica ahora los parches a las líneas compatibles y reinicia lo que sea necesario. En cuanto a las líneas de Node.js que el desarrollador original ha dejado sin atender, trasládalas a una versión ELS corregida tan pronto como se publique la correspondiente a tu línea; mientras tanto, reduce su exposición a datos Brotli no fiables y, a continuación, programa la migración en el calendario.

Consigue hoy mismo ELS para Runtimes →

Cómo se desarrollaron estos acontecimientos

Fuentes

Las fuentes de esta entrada incluyen el aviso de seguridad de Node.js del 21 de octubre de 2026, las notas de la versión 22.23.4 y 24.22.1, la prealerta en oss-security, el calendario de lanzamientos de Node.js, la confirmación de la corrección de google/brotli, la solicitud de incorporación de cambios de la lista de bloqueo de eMudhra, el boletín de seguridad de Vercel, la investigación «Node2Shell» de Imperva, la cobertura de The Hacker News, el catálogo KEV de la CISA, is-my-node-vulnerable y la documentación de TuxCare sobre ELS para entornos de ejecución de Node.js, así como datos de seguridad legibles por máquina.