Índice de contenidos
Claves de la noticia
- Node.js publica las versiones de seguridad 22.23.4, 24.22.1 y 26.12.1, con correcciones en DNS, TLS, Brotli, aleatoriedad y permisos.
- Un recuento de los identificadores del aviso oficial da diez vulnerabilidades: siete afectan a las tres ramas, una a 24 y 26 y dos solo a 26.
- Actualizar dependencias de una aplicación no equivale a reemplazar su ejecutable de Node.js; las imágenes y los procesos desplegados requieren comprobación propia.
Las actualizaciones de seguridad de Node.js anunciadas para este 21 de octubre ya están disponibles. El proyecto identifica fallos de gravedad alta en las tres ramas cubiertas. Para quienes mantienen servicios JavaScript, el dato decisivo es que el alcance cambia entre versiones, pero ninguna de esas ramas queda fuera de la actualización.
Siete fallos compartidos bajo tres números de versión
El aviso de seguridad de octubre enlaza las versiones 22.23.4, 24.22.1 y 26.12.1. Se trata de correcciones dentro de cada rama: una aplicación en 22 no necesita saltar automáticamente a 26 para recibir estos arreglos. La elección de una versión principal distinta depende además de compatibilidad, soporte y pruebas de la aplicación.
Un recuento propio toma cada identificador CVE una sola vez y anota las ramas que el aviso enumera como afectadas. El resultado es una matriz de diez fallos distintos, con siete compartidos por las tres ramas. No es un recuento de ataques ni de paquetes vulnerables instalados: mide exclusivamente el alcance declarado en el documento público.
| Rama | Versión corregida | CVE aplicables |
|---|---|---|
| 22 | 22.23.4 | 7 |
| 24 | 24.22.1 | 8 |
| 26 | 26.12.1 | 10 |
La diferencia sale de tres avisos: el de normalización de direcciones con dígitos de ancho completo alcanza a 24 y 26; los de cabeceras ZIP y búsqueda de permisos con comodines se circunscriben a 26. Eso no demuestra que la rama antigua sea más segura en términos generales. Tampoco contar CVE permite sumar sus gravedades: funciones diferentes y condiciones diferentes producen superficies de exposición diferentes.
Las notas de Node.js 22.23.4 incluyen validación de nombres DNS con bytes nulos, rechazo de direcciones IP no canónicas y cambios en el decodificador Brotli. También actualizan componentes como OpenSSL y Undici. Estos arreglos pertenecen al entorno de ejecución y sus bibliotecas incorporadas; revisar únicamente el listado de dependencias de la aplicación deja esa capa sin verificar.
Dos fronteras de confianza y un estado que se copia
En las notas de la rama 24, la normalización de IP aparece junto a la corrección específica de dígitos de ancho completo. La cuestión de fondo es si dos representaciones de una dirección reciben un tratamiento coherente durante la validación TLS. Para un servicio que llama a otros sistemas por HTTPS, comprobar el destino y validar su certificado forman parte de la confianza de esa conexión.
El arreglo de Brotli es otro asunto: el aviso lo describe como una escritura fuera de límites que permite ejecución remota de código. No hay que confundirlo con los cambios TLS ni deducir que todos los servicios aceptan los mismos datos comprimidos. La exposición concreta depende de cómo use cada aplicación las funciones afectadas. El comunicado no ofrece una cifra de servicios españoles comprometidos.
La publicación de Node.js 26.12.1 reúne además cambios en archivos ZIP y en el árbol de permisos. El compromiso de certificados de eMudhra también forma parte de las actualizaciones del conjunto de confianza, un antecedente que ya explicamos al analizar por qué cada producto debe renovar sus propios almacenes. Esta noticia amplía la respuesta con parches del runtime y no vuelve a publicar aquel incidente como si acabara de ocurrir.
Hay un fallo menos visible que merece atención separada. El CVE-2026-106074 afecta a cachés de aleatoriedad conservadas en instantáneas de arranque creadas por el usuario y aplicaciones ejecutables autocontenidas. El aviso explica que distintos procesos pueden repetir valores de randomUUID() y randomInt(). No afirma que toda llamada a esas funciones, en cualquier aplicación Node.js, repita resultados.
La documentación de instantáneas de arranque de V8 describe un mecanismo para conservar estado preparado durante la construcción y recuperarlo al iniciar la aplicación. De esa arquitectura se deriva una comprobación útil: cuando el estado se guarda dentro de un artefacto distribuido, revisar únicamente el intérprete instalado en el servidor no acredita que ese artefacto se haya reconstruido con la corrección. Conviene distinguir el origen de construcción del binario que finalmente se ejecuta.
El despliegue debe demostrar qué ejecutable está en uso
Para un equipo que publica una API, una tienda o un servicio de integración, la revisión puede organizarse por unidad desplegada: rama de Node.js, imagen o paquete que la contiene y proceso que atiende las peticiones. Dos servicios de la misma empresa pueden usar versiones distintas aunque compartan repositorio. La comprobación debe seguir esa distribución real, en lugar de dar por actualizado todo el entorno a partir del portátil del desarrollador.
También importa elegir una rama mantenida. El calendario oficial de versiones distingue las fases Current y LTS y recomienda utilizar versiones Active LTS o Maintenance LTS en producción. El parche de hoy y una migración de rama son decisiones separadas: la actualización urgente corrige fallos conocidos; el calendario determina cuánto mantenimiento puede esperarse después.
Esta diferencia entre disponibilidad y despliegue ya resultaba relevante en la revisión de la actualización de JDK 21. Aquí, la conclusión que deja la matriz es más inmediata: los siete fallos comunes impiden excluir cualquiera de las tres ramas del plan de actualización. El número de versión del proceso desplegado es la evidencia de cierre que falta cuando solo se ha descargado un parche.
Imagen: recreación conceptual generada por IA de un entorno de trabajo técnico; no muestra una aplicación ni una intrusión reales.
