Qué publicó Node.js y por qué conviene mirarlo
El aviso reúne diez vulnerabilidades del runtime, cuatro con severidad alta. Entre ellas hay problemas en la validación de certificados TLS, el procesamiento de respuestas en conexiones keep-alive, la resolución DNS y el decodificador Brotli. El proyecto también actualizó componentes incluidos en Node.js, como c-ares, certificados de CA y Undici. No todas las aplicaciones usan cada función afectada, pero el equipo debe revisar el aviso contra su configuración real.
La corrección más urgente no depende de instalar una versión nueva de un paquete con npm: se trata de versiones nuevas del propio Node.js. Si una API, un worker, una herramienta de build o un proceso del servidor ejecuta una versión anterior, actualizar solo package-lock.json no cambia ese runtime.
El aviso menciona además fallas de severidad media y baja, incluidas situaciones relacionadas con snapshots de inicio, el módulo ZipFile y el Permission Model. La exposición depende de cómo se use cada función. No hace falta intentar reproducir un exploit en producción para decidir si corresponde instalar la versión corregida.
| Aviso | Severidad | Ramas afectadas | Área descrita por Node.js |
|---|---|---|---|
| CVE-2026-105482 | High | 22.x, 24.x, 26.x | dns.resolve con nombres que contienen NUL |
| CVE-2026-105483 | High | 24.x, 26.x | Validación TLS con dígitos de ancho completo |
| CVE-2026-106069 | High | 22.x, 24.x, 26.x | Validación de hostname TLS |
| CVE-2026-111497 | High | 22.x, 24.x, 26.x | Decodificador Brotli |
| CVE-2026-105481 | Medium | 22.x, 24.x, 26.x | Respuestas en sockets keep-alive |
| CVE-2026-106072 | Medium | 22.x, 24.x, 26.x | Validación de certificados para IPv4 no canónico |
| CVE-2026-106074 | Medium | 22.x, 24.x, 26.x | Caché de entropía en snapshots y SEA |
| CVE-2026-106070 | Low | 26.x | Validación de encabezado ZIP |
| CVE-2026-106071 | Low | 26.x | Permission Model y comodines |
| CVE-2026-106073 | Low | 22.x, 24.x, 26.x | Permission Model y fs.realpathSync |
Versiones corregidas
Para las ramas cubiertas por el aviso, las versiones publicadas son Node.js 22.23.4, 24.22.1 y 26.12.1. El aviso indica que las versiones fuera de soporte también deben considerarse afectadas cuando se publica una actualización de seguridad. Si usás una rama anterior, revisá su estado de soporte con Node.js y planificá el paso a una versión mantenida.
Estos números son los releases upstream. Una imagen de contenedor, distribución o servicio administrado puede distribuir el runtime de otra manera. Consultá el boletín de quien mantiene ese paquete y confirmá qué versión está activa dentro del proceso que recibe tráfico.
| Rama | Versión corregida publicada |
|---|---|
| Node.js 22.x | 22.23.4 |
| Node.js 24.x | 24.22.1 |
| Node.js 26.x | 26.12.1 |
Primero, encontrá dónde corre Node.js
Es común que el equipo conozca la versión del portátil y del pipeline, pero no la del servicio que está atendiendo solicitudes. Reuní el inventario de aplicaciones web, APIs, workers, tareas programadas, herramientas internas, imágenes Docker, entornos de CI y funciones administradas. En un repositorio, buscá también las imágenes base y los archivos que fijan la versión del runtime.
Anotá servicio, entorno, versión, origen del paquete o imagen, responsable, dependencias operativas y procedimiento de rollback. Comprobá la versión desde el contenedor o entorno real de ejecución, no desde una terminal distinta. Evitá publicar endpoints de diagnóstico que revelen información del sistema.
Actualizar sin perder de vista el runtime
Elegí el paquete o imagen corregida indicada por el proveedor. Si Node está dentro de una imagen, cambiá la imagen base y construí una imagen nueva; actualizar el host no modifica automáticamente el Node empaquetado en el contenedor. Revisá también los workers y procesos secundarios: pueden usar una imagen o configuración distinta de la API principal.
Desplegá primero en un entorno representativo, verificá la versión desde el proceso activo y seguí los pasos de reinicio o reemplazo de instancias que indique el proveedor. Si dependés de una plataforma administrada, pedí confirmación de la versión aplicada y de cuándo se reciclaron los procesos. Guardá una ruta de rollback que el equipo haya comprobado.
Cómo armar la regresión
La regresión busca cambios no deseados en el comportamiento del producto después de actualizar el runtime. No demuestra por sí sola que la vulnerabilidad esté corregida, que no queden otras vulnerabilidades ni que todos los servidores hayan sido actualizados. Para esas preguntas, verificá el runtime, el inventario y el análisis de dependencias por separado.
Empezá por los usos reales de Node en el servicio. Si la aplicación hace solicitudes HTTPS, revisá conexiones a servicios internos y externos, validación de certificados, timeouts y reintentos. Si recibe o produce contenido comprimido, ejercitá las rutas habituales con datos de prueba. Para APIs con keep-alive, comprobá respuestas, errores y reutilización normal de conexiones. No hace falta enviar entradas maliciosas: probá los contratos y recorridos legítimos del producto.
Sumá el inicio de la aplicación, autenticación, permisos, operaciones de negocio principales, persistencia, colas, tareas programadas y señales de salud. Elegí pruebas según el uso de cada servicio; no marques como aplicable una función solo porque aparece en la lista del aviso. Registrá build, ambiente, versión, datos sintéticos, resultado esperado, resultado observado y evidencia sin secretos.
Ejemplos de casos para adaptar
Estos casos son un punto de partida, no una suite universal. Ajustalos a las rutas, integraciones y condiciones que existan en tu producto. Ejecutalos en un entorno autorizado, con cuentas y datos de prueba.
| Área | Qué probar | Qué registrar |
|---|---|---|
| Inicio y salud | Arranque, readiness y respuesta básica del servicio. | Versión del proceso, build, ambiente y salida saneada. |
| HTTPS y certificados | Conexiones habituales a dependencias; éxito, error y timeout. | Destino de prueba, resultado TLS, estado y logs sin credenciales. |
| API y keep-alive | Solicitudes consecutivas válidas y manejo normal de errores. | Request ID ficticio, status, latencia y respuesta esperada. |
| Contenido comprimido | Flujos legítimos de lectura o entrega de contenido comprimido. | Tipo de contenido, tamaño de prueba y resultado. |
| Autenticación y permisos | Inicio/cierre de sesión y accesos permitidos y denegados. | Rol de prueba y resultado; nunca cookies ni tokens. |
| Workers y colas | Procesamiento, reintento y recuperación de tareas normales. | ID ficticio, tiempos, estado final y logs redactados. |
| Persistencia | Crear, consultar y modificar datos de prueba. | IDs sintéticos y comprobación antes/después. |
Cuándo dar por terminada la revisión
Antes del cambio, acordá qué fallas frenan el despliegue. Una versión activa que no se puede confirmar, errores nuevos sin explicación, fallas en autenticación o permisos, pérdida de datos, colas atascadas o integraciones críticas rotas deberían detener la promoción hasta entender el impacto.
Al cierre, separá lo aprobado, lo fallido, lo bloqueado y lo que no aplica. Anotá los riesgos abiertos y quién los revisará. Un caso bloqueado no cuenta como aprobado, y una regresión verde solo habla de los recorridos que realmente se ejecutaron.
Fuentes oficiales de Node.js
- Node.js: aviso de seguridad del 21 de octubre de 2026
- Calendario oficial de lanzamientos
- Política de seguridad de Node.js
- Descargas oficiales de Node.js
Guía informativa para planificar QA. No reemplaza el aviso de seguridad, las instrucciones del proveedor ni una evaluación de seguridad. Revisada el 22 de octubre de 2026.