La vulnerabilidad de Node.js de octubre de 2026 obliga a actualizar como mínimo a Node.js 22.23.4, 24.22.1 o 26.12.1, según la rama utilizada. Publicadas el 21 de octubre de 2026, estas versiones corrigen diez CVE, entre ellas cuatro vulnerabilidades de gravedad alta. La prioridad consiste en inventariar cada entorno y, después, reconstruir y volver a desplegar las aplicaciones para garantizar que el motor que se ejecuta realmente esté corregido.
¿Qué versiones corrigen la vulnerabilidad de Node.js de octubre de 2026?
Las correcciones de seguridad de Node.js del 21 de octubre de 2026 están integradas en las versiones 22.23.4 LTS, 24.22.1 LTS y 26.12.1 Current. Toda versión anterior perteneciente a las ramas 22.x, 24.x o 26.x debe actualizarse. Una rama que ha llegado al final de su vida útil no recibe estas correcciones oficiales.
Node.js est un environnement d’exécution qui permet notamment de faire fonctionner du JavaScript côté serveur. Il peut alimenter une API, le serveur d’un site construit avec Next.js, un traitement automatisé ou un outil interne. La version présente sur le poste d’un développeur ne prouve donc rien sur celle qui tourne en production.
| Rama utilizada | Versión mínima corregida | Estado publicado | Acción |
|---|---|---|---|
| Node.js 22.x | 22.23.4 | LTS | Actualizar cualquier versión 22.x anterior |
| Node.js 24.x | 24.22.1 | LTS | Actualizar cualquier versión 24.x anterior |
| Node.js 26.x | 26.12.1 | Current | Actualizar cualquier versión 26.x anterior |
| Rama al final de su vida útil | Ninguna versión corregida en la rama antigua | No compatible | Migrar a una rama LTS mantenida |
El error clásico consiste en actualizar Node.js en el servidor anfitrión mientras la aplicación utiliza su propio motor en una imagen de Docker. Ocurre lo mismo con un artefacto de despliegue, una instantánea o una aplicación monoejecutable: el binario vulnerable puede permanecer incluido en ellos.
Node.js 22.23.4 también actualiza c-ares a 1.34.9, OpenSSL a 3.5.9, SQLite a 3.53.4 y Undici a 6.29.1. Node.js 24.22.1 incluye, entre otros, c-ares 1.34.9, OpenSSL 3.5.9 y Undici 7.30.1, según las notas de publicación del proyecto Node.js de 2026.
¿Cuál es el riesgo real de la vulnerabilidad de Brotli CVE-2026-111497?
La vulnerabilidad CVE-2026-111497 es una escritura fuera de límites en el decodificador Brotli integrado en Node.js. Un contenido Brotli manipulado puede superar un búfer de memoria y provocar un cierre inesperado, una divulgación de memoria o la ejecución remota de código. No obstante, la exposición exige que la aplicación descomprima datos controlados por un atacante.
Brotli es un algoritmo de compresión utilizado para reducir el tamaño de los datos. Una escritura fuera de límites significa que un programa escribe fuera de la zona de memoria prevista. El impacto potencial es grave, pero ejecutar una versión vulnerable no basta para demostrar que un sitio pueda explotarse de forma remota.
El 23 de octubre de 2026, la Cyber Security Agency of Singapore atribuyó a CVE-2026-111497 una puntuación CVSS v3.1 de 9,8 y recomendó una corrección inmediata. Por su parte, Node.js clasifica la vulnerabilidad como High. Estas dos evaluaciones emplean métodos o escalas diferentes; no cambian las versiones que deben instalarse.
A fecha del 23 de octubre de 2026, Red Hat indicaba que no disponía de pruebas públicas y fiables de ejecución remota de código. Rapid7 señaló el 26 de octubre de 2026 que no conocía ninguna explotación activa y precisó que la CVE tampoco figuraba en el catálogo Known Exploited Vulnerabilities de la CISA. Esto justifica una actualización rápida, pero no afirmar que exista un compromiso generalizado.
¿Qué corrigen las otras nueve vulnerabilidades de Node.js?
Las actualizaciones de Node.js de octubre de 2026 corrigen nueve vulnerabilidades adicionales: tres de gravedad alta, tres medias y tres bajas. Los riesgos afectan, entre otros aspectos, a la resolución DNS, la verificación de nombres de host TLS, las conexiones HTTP persistentes, las direcciones IPv4, los valores aleatorios y determinados controles de permisos sobre archivos.
Las otras tres vulnerabilidades de gravedad alta son CVE-2026-105482, relacionada con un truncamiento por byte nulo en DNS, así como CVE-2026-105483 y CVE-2026-106069, dos omisiones de la verificación del nombre de host TLS. TLS es el protocolo que protege las comunicaciones de red y verifica, entre otros aspectos, la identidad del servidor contactado.
CVE-2026-105483 afecta a las ramas 24.x y 26.x, según el aviso de Node.js del 21 de octubre de 2026; la rama 22.x no figura como afectada. Esta precisión cuenta a la hora del análisis, pero no debe llevar a retrasar la corrección global de una rama que incluye otras vulnerabilidades.
Las vulnerabilidades de gravedad media afectan al tratamiento de las respuestas HTTP keep-alive con CVE-2026-105481, a los nombres de host IPv4 no canónicos con CVE-2026-106072 y a la repetición de valores aleatorios en instantáneas o aplicaciones monoejecutables con CVE-2026-106074. Una conexión keep-alive permanece abierta para transportar varias comunicaciones sin tener que volver a conectarse sistemáticamente.
Las vulnerabilidades de gravedad baja son CVE-2026-106070 en la API ZipFile de Node.js 26.x, CVE-2026-106071 en el modelo de permisos de Node.js 26.x y CVE-2026-106073 en los controles de permisos de fs.realpathSync() para las ramas 22.x, 24.x y 26.x. Al igual que ocurre con los riesgos asociados a las vulnerabilidades de PHP, la gravedad teórica debe ponerse en relación con las funciones realmente expuestas.
¿Cómo verificar Node.js en los servidores, Docker y la CI?
El inventario de la vulnerabilidad de Node.js de octubre de 2026 debe abarcar los motores instalados en los hosts, los procesos en servicio, los contenedores activos, las imágenes de Docker, las cargas de trabajo de Kubernetes y las canalizaciones de integración continua. El comando node --version es útil, pero su resultado debe registrarse en el contexto exacto en el que se ejecuta cada aplicación.
Un servidor puede contener varios ejecutables de Node.js. La cuenta del sistema del servicio también puede utilizar una ruta distinta de la de una sesión de administrador. En el caso de una agencia, la práctica recomendada es comprobar el binario iniciado por el gestor de procesos en lugar de limitarse a la versión mostrada en un terminal.
La auditoría operativa debe seguir estos puntos, en este orden:
- Registrar
node --version, la ruta del ejecutable y el entorno de las unidades de servicio en cada host. - Comprobar la versión dentro de cada contenedor activo con
docker exec node --version. - Leer los archivos Dockerfile y sus imágenes base, incluidas las etiquetas que puedan apuntar a contenido antiguo.
- Examinar las imágenes declaradas en las cargas de trabajo de Kubernetes y los registros donde se almacenan.
- Vérifier les versions Node.js déclarées dans les workflows CI, les outils de build et les fichiers de configuration.
- Identificar las instantáneas, los artefactos y las aplicaciones monoejecutables que incluyen su propio runtime.
En Docker, sustituir únicamente una etiqueta en un archivo sin reconstruir la imagen deja sin cambios los contenedores existentes. Este tipo de discrepancia también explica por qué la corrección de una vulnerabilidad en Docker exige controlar la imagen que se está ejecutando realmente, y no solo la configuración prevista.
¿Cómo desplegar las correcciones sin interrumpir la aplicación?
El despliegue de las correcciones de Node.js debe pasar por un entorno de pruebas y, a continuación, por la reconstrucción de las imágenes y los artefactos antes de realizar un redespliegue progresivo. Es necesario reiniciar los procesos de Node.js. Una sustitución por lotes detrás de un balanceador de carga permite mantener el servicio si la arquitectura cuenta con varias instancias en buen estado.
Comience con una copia de seguridad utilizable y pruebe los flujos esenciales: inicio de sesión, pagos, envío de correos electrónicos, importación de archivos, llamadas a API y tareas programadas según el proyecto. A continuación, compruebe los registros, los errores HTTP y el uso de los recursos. Una actualización del runtime puede revelar una dependencia obsoleta, aunque la corrección de seguridad en sí siga siendo compatible con la rama.
Para un contenedor, reconstruya desde una imagen base corregida, publique la imagen con un identificador inmutable y, a continuación, despliéguela. Kubernetes debe crear nuevos pods; reiniciar un contenedor antiguo basado en la misma imagen vulnerable no corrige nada. La misma lógica se aplica a la CI: los entregables deben regenerarse con el runtime corregido.
Sinceramente, mantener una rama de Node.js al final de su vida útil para evitar una campaña de pruebas repetida aumenta el riesgo ante el próximo aviso de seguridad. Llegados a este punto, es preferible planificar una migración a una rama LTS mantenida, aunque haya que separar la corrección inmediata de la modernización de la aplicación. La elección de la arquitectura, especialmente entre Astro y Next.js para un proyecto web, también debe tener en cuenta la política de mantenimiento del runtime.
Después del despliegue, vuelva a comprobar la versión desde cada proceso o contenedor activo. Conserve pruebas de la versión, de la imagen desplegada, de la fecha y del resultado de las pruebas. Una simple modificación en el repositorio Git no demuestra que se haya corregido el entorno de producción.
Cadrer l’inventaire, les tests et le retour arrière avant l’intervention évite la plupart des mauvaises surprises. Un regard extérieur peut surtout aider lorsque plusieurs serveurs, conteneurs et pipelines embarquent des versions différentes du même runtime.
Preguntas frecuentes sobre las correcciones de Node.js de octubre de 2026
¿Es un sitio Node.js forcément pirateable de forma remota?
Un sitio Node.js vulnerable no es forcément explotable de forma remota. CVE-2026-111497 requiere que la aplicación descomprima con Brotli datos controlados por un atacante, pero sigue siendo recomendable instalar la actualización sin esperar a que se demuestre su explotación.
¿Basta con actualizar Node.js en el servidor con Docker?
Actualizar Node.js en el host no corrige el motor incluido en una imagen de Docker. La imagen debe reconstruirse a partir de una base corregida; después, hay que recrear los contenedores y comprobar su versión.
¿Qué comando muestra la versión de Node.js?
El comando node --version muestra la versión de Node.js disponible en el entorno actual. Ejecútelo también en los contenedores y con la cuenta utilizada por el servicio para evitar comprobar el binario equivocado.
¿Se puede seguir utilizando una versión anterior de Node.js?
Una rama de Node.js al final de su vida útil no recibe las correcciones de seguridad publicadas por el proyecto. Una aplicación en producción debe migrar a una rama LTS compatible en lugar de considerar que su versión principal antigua está corregida.