Qué corrige la publicación de Node.js de octubre de 2026
El 21 de octubre de 2026, Node.js publicó actualizaciones para las líneas 22.x, 24.x y 26.x. Entre las diez vulnerabilidades corregidas, el proyecto clasifica CVE-2026-111497 como High: el decodificador Brotli incorporado escribe más allá de un búfer interno cuando recibe datos mal formados. En concreto, un cambio de bloque no válido se notificaba como una simple necesidad de más datos, y no como un error de formato definitivo. El decodificador en flujo seguía entonces añadiendo bytes a un búfer interno de ocho bytes. Las consecuencias posibles van desde la caída del proceso hasta la divulgación de memoria y la ejecución remota de código con los privilegios del proceso Node.
Sobre la gravedad coexisten dos lecturas. Node.js dice High; Google, como autoridad de numeración de CVE, asigna una puntuación CVSS v4 de 9,2, según el análisis de Rapid7. A 26 de octubre de 2026, Rapid7 no conoce ninguna explotación en la práctica, y el fallo no figura en el catálogo CISA de vulnerabilidades explotadas. El fallo no está, por tanto, explotado hasta ahora, según Rapid7: es una ventana para parchear con calma, no un motivo para esperar.
Versiones afectadas y versiones corregidas
Desplace la tabla
| Caso | Estado | Acción |
|---|---|---|
| Node.js 22.x | Afectada antes de 22.23.4 | Pasar a 22.23.4 |
| Node.js 24.x | Afectada antes de 24.22.1 | Pasar a 24.22.1 |
| Node.js 26.x | Afectada antes de 26.12.1 | Pasar a 26.12.1 |
| Node.js 20.x y otras líneas al final de su vida útil | Tratar como afectadas, sin corrección | Migrar a 22.x o 24.x |
| Imagen Docker node:<línea> | Afectada hasta que se reconstruya la imagen | Reconstruir con --pull --no-cache |
| Binario de Node empaquetado en una herramienta (Electron, ejecutable empaquetado) | Depende de la versión incorporada | Actualizar la propia herramienta |
| Otro software que incorpora el mismo decodificador Brotli | Según el proveedor | Leer su propio aviso |
Está expuesto: el criterio que decide
Tener un Node vulnerable no basta para ser atacable. El aviso de Node.js apunta a una aplicación que descomprime con node:zlib datos Brotli suministrados por un atacante, mediante zlib.createBrotliDecompress o zlib.brotliDecompress. Rapid7 precisa que la mera presencia del decodificador no establece la exposición: todo depende de lo que la aplicación descomprime. Sin embargo, no concluya demasiado rápido que no hay riesgo, porque Brotli suele pasar por bibliotecas que usted no escribió.
El vínculo con la cabecera Content-Encoding: br es nuestra lectura, no una afirmación del aviso. En el código fuente público, el fetch integrado en Node (undici) decodifica las respuestas br con zlib.createBrotliDecompress, el adaptador HTTP de axios prevé la misma decodificación y el código actual de body-parser hace lo mismo con los cuerpos de las peticiones entrantes. Hay que examinar por tanto dos flujos: lo que su aplicación recibe de los clientes y lo que obtiene de servidores de terceros. Puede comprobarlo en su propio árbol de dependencias con los comandos del inventario más abajo.
Por dónde puede entrar Brotli no confiable en una aplicación Node
- Peticiones entrantes comprimidas — una API Express o un servidor propio que usa body-parser descomprime un cuerpo
Content-Encoding: brenviado por cualquier cliente. - Respuestas de servicios de terceros —
fetcho axios que llama a una API, un feed RSS, un webhook o una página para previsualizar: el servidor remoto elige la codificación de la respuesta. - Renderizado en el servidor — una aplicación Next o Nuxt que obtiene datos remotos durante el renderizado pasa por esas mismas llamadas salientes.
- Proxies y pasarelas escritos en Node — un componente que descomprime para inspeccionar o transformar el contenido en tránsito abre ambos flujos a la vez.
- Tratamiento de archivos — un servicio que acepta archivos comprimidos con Brotli y los abre con
zlib.brotliDecompress. - Herramientas de compilación y CI — scripts de despliegue y tareas que descargan artefactos: menos expuestos, pero usan el mismo binario y se parchean al mismo tiempo.
- Ninguna ruta identificada — prioridad más baja, no nula: una dependencia añadida más tarde basta para crear la exposición, y la publicación corrige además otros fallos.
Inventariar el parque en quince minutos
Leer la versión de cada máquina
node -vwhich -a node
Suelen convivir varios binarios: el del sistema, el de nvm, el de un contenedor.which -alos lista todos, y el primero no siempre es el que usa el servicio.Encontrar el binario real de cada proceso
ps -eo pid,user,args | grep -E '[n]ode|[p]m2'sudo readlink -f /proc/<pid>/exe
La segunda orden, lanzada con el PID obtenido, da la ruta exacta del binario que ejecuta el proceso. Es la única respuesta fiable en una máquina con varias instalaciones de Node.Consultar los contenedores
docker psdocker exec <conteneur> node -vdocker images | grep node
Un contenedor en ejecución no se corrige solo: conserva la imagen con la que arrancó, aunque exista una más reciente en la máquina.Buscar las llamadas directas en su código
grep -rEn "createBrotliDecompress|brotliDecompress" --include=*.js --include=*.mjs --include=*.ts . --exclude-dir=node_modules
Cada línea encontrada es un punto donde su código descomprime Brotli. Mire de dónde vienen los datos: un archivo que usted mismo produjo no tiene el mismo riesgo que el cuerpo de una petición.Buscar las bibliotecas que descomprimen por usted
grep -rlE "createBrotliDecompress" node_modules --include=*.jsnpm ls body-parser axios undici
La primera orden lista los paquetes instalados que llaman al decodificador; la segunda muestra qué versiones de body-parser, axios y undici hay en el proyecto. Lance ambas en cada repositorio, no solo en el más reciente.Localizar los binarios empaquetados
Las herramientas que incorporan su propio Node (aplicaciones Electron, ejecutables empaquetados) no quedan cubiertas por
apt. Consulte su versión en su documentación y compruebe si el proveedor ha publicado una versión corregida.Anotar el resultado en una tabla
Una fila por proceso: máquina, cliente, línea de Node, versión, ruta Brotli identificada o no. Esta tabla decide el orden de tratamiento y servirá de prueba una vez hecha la actualización.
En qué orden tratar el parque
Un parque de sitios de clientes, con versiones e instalaciones heterogéneas, no se actualiza de un solo gesto, y no hace falta. Empiece por los servidores expuestos a Internet que reciben cuerpos comprimidos o llaman a servicios de terceros: renderizado en el servidor, pasarelas, proxies, API públicas. Siguen las aplicaciones internas y los workers, y después las herramientas de compilación. Las aplicaciones en Node 20 son un caso aparte: no habrá corrección para ellas y la única salida es migrar a 22.x o 24.x, algo que conviene planificar con el cliente en lugar de improvisar. Avance por tramos de unas pocas máquinas y verifique cada tramo antes de pasar al siguiente.
Actualizar según el modo de instalación
Paquete apt (repositorio NodeSource o distribución)
apt-cache policy nodejssudo apt-get updatesudo apt-get install --only-upgrade nodejsnode -v
Lea primero la fuente que muestraapt-cache policy: el repositorio debe apuntar a la línea correcta (node_22.x o node_24.x). Un repositorio que se quedó en una línea al final de su vida útil nunca ofrecerá la corrección. Un paquete de distribución también puede llevar otro número: compárelo con el aviso de su distribución.nvm
nvm install --reinstall-packages-from=current 22nvm alias default 22nvm use 22node -v
La orden instala la última 22.x disponible; compruebe quenode -vmuestra 22.23.4 o superior. Haga lo mismo con 24 si es su línea. Los servicios lanzados por otro usuario tienen su propio nvm.Docker
Cambie la etiqueta de la línea
FROM, por ejemploFROM node:22oFROM node:24con la variante que ya utiliza, y luego:docker build --pull --no-cache -t monapp:corrige .docker compose up -d
La opción--pulldescarga la última versión de la imagen base y--no-cacheevita reutilizar una capa construida con el Node antiguo. El contenedor en ejecución solo se sustituye al volver a desplegar.pm2
pm2 restart allpm2 update
Tras sustituir el binario,pm2 restartrelanza las aplicaciones;pm2 updateactualiza el demonio de pm2 en memoria. La documentación de pm2 añade que, tras una actualización de Node, conviene refrescar también el script de arranque:pm2 unstartuppm2 startuppm2 saveServicio systemd u otro supervisor
sudo systemctl restart <service>
Reinicie cada servicio uno a uno, comprobando su registro y su ruta de salud antes de pasar al siguiente. En una aplicación detrás de un balanceador, saque la máquina del grupo mientras dura el reinicio.
Un proceso ya iniciado conserva el Node antiguo
Sustituir el binario no corrige los procesos en ejecución: conservan la versión antigua en memoria hasta que se reinician. Un node -v correcto en la máquina no prueba nada sobre un servicio iniciado ayer. Tras cada reinicio, verifique desde el propio proceso: pm2 jlist o pm2 show <nom> para la versión de Node en uso, o process.version expuesto en su ruta de salud.
Si hoy es imposible actualizar
Node.js no ha publicado ninguna solución alternativa: la única mitigación del proveedor es la versión corregida. En su defecto, Rapid7 recomienda restringir o desactivar las rutas de la aplicación que descomprimen Brotli no confiable. Así se traduce en la práctica. Los puntos siguientes son medidas de reducción del riesgo que proponemos nosotros, no recomendaciones del proveedor, y ninguno sustituye a la corrección.
En las peticiones entrantes, rechace Brotli en el proxy inverso, por ejemplo en nginx: if ($http_content_encoding ~* br) { return 415; }. Pruebe con nginx -t antes de recargar y compruebe que ninguno de sus clientes legítimos envía cuerpos en br. En las respuestas de terceros, anuncie solo las codificaciones útiles con la cabecera Accept-Encoding: gzip y limite los destinos permitidos de sus llamadas salientes. Esta última medida es parcial: un servidor malicioso puede responder en br aunque no se lo hayan pedido, y el decodificador sigue la cabecera de la respuesta. En Vercel, las reglas WAF bloquean el flujo entrante pero no las respuestas que obtienen sus funciones; sigue siendo necesario volver a desplegar con una versión corregida.
No corrija solo el fallo de Brotli
La misma publicación corrige otros nueve fallos. Entre ellos figuran dos elusiones de la verificación del nombre de host TLS de gravedad alta, CVE-2026-105483 y CVE-2026-106069, y también CVE-2026-105482, un truncamiento de los nombres de host que contienen un carácter NUL en las resoluciones DNS, igualmente clasificado High. No afectan todos a las mismas líneas: CVE-2026-105483 concierne a las líneas 26.x y 24.x, y los otros dos afectan también a 22.x. Una aplicación que valida certificados TLS en sus llamadas salientes tiene por tanto buenas razones para pasar a la versión corregida sin esperar a resolver la cuestión de Brotli.
Para una agencia: una corrección por línea, no por sitio
Cuando se llevan decenas de sitios, la orden de actualización tarda un minuto; el tiempo se va en otra parte. Hay que averiguar qué máquina ejecuta qué versión para qué cliente y conseguir después una ventana de reinicio. Mantenga por tanto un registro vivo, alimentado con el inventario anterior: ante el próximo fallo, un simple filtro sobre la línea de Node da la lista de sitios que tratar. Cuantas menos variantes haya en el parque, menos casos que gestionar a mano, y el alojamiento de revendedor responde a esa lógica: una interfaz única para la cartera y renovaciones agrupadas, frente a un conjunto de servidores dispares que multiplica los accesos que seguir. Las aplicaciones atadas a Node 20 requieren un tratamiento aparte: la guía de migración enlazada bajo este artículo evita descubrir la ausencia de corrección el día del siguiente fallo.
La documentación oficial
Aviso de seguridad de Node.js de octubre de 2026: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
Análisis de Rapid7 sobre CVE-2026-111497: https://www.rapid7.com/blog/post/etr-cve-2026-111497-critical-out-of-bounds-write-in-the-node-js-brotli-decoder/
Boletín de Vercel: https://vercel.com/kb/bulletin/node-js-security-advisory
Documentación del módulo zlib: https://nodejs.org/api/zlib.html
Documentación de nvm: https://github.com/nvm-sh/nvm
Actualización de pm2: https://pm2.keymetrics.io/docs/usage/update-pm2/
Opciones de docker build: https://docs.docker.com/reference/cli/docker/buildx/build/
