Actualización de seguridad de Node.js de julio de 2026: versiones, 11 CVE y guía de actualización

Respuesta directa: los parches de seguridad de Node.js de julio de 2026 ya están disponibles. Si tu servicio sigue en la rama 22, 24 o 26, actualiza como mínimo a 22.23.2 LTS, 24.18.1 LTS o 26.5.1 Current, respectivamente. No intentes corregir el runtime con npm update: npm gestiona paquetes de la aplicación, no sustituye el binario de Node.js.

El proyecto Node.js publicó las versiones el 29 de julio de 2026, después de aplazar el lanzamiento previsto el 27 y después el 28 por validación adicional y problemas de infraestructura. El boletín oficial de seguridad confirma 11 CVE y enlaza las tres versiones corregidas.

Resumen ejecutivo

• Acción mínima: conserva tu rama principal durante la respuesta al incidente y súbela a 22.23.2, 24.18.1 o 26.5.1. Una migración de rama puede planificarse aparte para no mezclar el parche urgente con cambios de compatibilidad.
• Prioridad más alta: servicios que exponen HTTP/2, ejecutan código confiable con --permission cuando un atacante puede influir en rutas o entradas, reutilizan agentes HTTPS con mTLS o políticas de identidad distintas, o funcionan como proxies de reenvío.
• Alcance: Node.js clasifica tres problemas como altos, cinco como medios y tres como bajos. El boletín no publica puntuaciones CVSS numéricas.
• Explotación: Las fuentes oficiales consultadas no confirman explotación activa. Eso no reduce la necesidad de actualizar: varios fallos permiten agotamiento de memoria, caída del proceso o ruptura de límites de seguridad.
• Fin de vida: si ejecutas una rama EOL, migra a una rama soportada; este boletín no ofrece un parche público para versiones EOL.

Versión corregida y acción por rama de Node.js

El estado de 22.x, 24.x y 26.x procede del calendario oficial del Release Working Group. La lista de distribuciones permite comprobar que las versiones están marcadas como lanzamientos de seguridad en el índice oficial de Node.js.

Qué corrigen las 11 CVE

La tabla siguiente separa severidad, componente, consecuencia y ramas afectadas. “Afecta” describe el alcance publicado por Node.js; la exposición real de cada aplicación depende de las funciones que utilice y de qué entradas pueda controlar un atacante.

CVE incluidas en la actualización de seguridad de Node.js de julio de 2026

Las notas de 22.23.2, 24.18.1 y 26.5.1 documentan qué corrección entró en cada rama y las versiones de llhttp y undici incorporadas.

Cómo priorizar según la exposición

No existe una prioridad universal basada solo en el número de CVE. Empieza por la ruta de ataque que realmente tiene tu servicio:

1. HTTP/2 expuesto a Internet: trata 56846 y 56848 como actualización urgente. Comprueba tanto los servidores Node que terminan HTTP/2 directamente como los despliegues donde el proxy entrega HTTP/2 al proceso Node.
2. Permission Model con código confiable y rutas o entradas influenciables por un atacante: prioriza 58043 y revisa también 56847 y 58039. Según la documentación oficial del Permission Model, es un control de defensa en profundidad para código confiable; no es un sandbox frente a código malicioso. El aislamiento del sistema operativo y de contenedores es un control independiente.
3. mTLS o varios contextos de identidad en un mismo agente HTTPS: prioriza 56850 y 58040, especialmente en integraciones B2B, agentes internos y clientes que reutilizan conexiones.
4. node:sqlite con SQLTagStore: 58041 solo aplica a 24.x y 26.x. Revisa flujos de escritura e idempotencia durante la validación.
5. DNS influenciable por entradas externas: 58042 puede terminar el proceso cuando dns.resolveAny() procesa una respuesta con más de 256 registros A. Prioriza servicios que resuelven nombres suministrados por usuarios o terceros.
6. Objetos pasados a las API síncronas de zlib: 58045 requiere que se pueda influir en el objeto o en la longitud TypedArray entregada a la API. El boletín no afirma que cualquier archivo comprimido externo baste para activar el fallo.
7. Proxy de reenvío escrito en Node: 58044 merece atención aunque su severidad sea baja. El patrón vulnerable combina reconstrucción de cabeceras visibles, canalización del cuerpo original y reutilización de la conexión backend.

Deshabilitar temporalmente HTTP/2 donde no sea necesario, separar agentes por identidad, limitar entradas influenciables por atacantes o reforzar aislamiento puede reducir exposición mientras se abre una ventana de mantenimiento. Son mitigaciones parciales; no sustituyen el runtime corregido.

Procedimiento seguro de actualización

1. Haz inventario del runtime real

No confíes solo en un package.json. Registra la versión y la ruta del binario que usa tu shell, el gestor de procesos, la unidad systemd y cada contenedor. Revisa también archivos .nvmrc, FROM en Dockerfile, imágenes de Compose y configuración CI/CD.

npm --version sirve para el inventario, pero npm update no instala una versión corregida de Node.js. El parche debe aplicarse al runtime con el mecanismo que lo suministra.

2. Define respaldo, prueba y rollback antes de cambiar

Guarda la versión anterior, la configuración del servicio, el inventario de dependencias y el identificador inmutable de la imagen. Usa además el procedimiento de respaldo de datos de tu aplicación; una copia del binario de Node no protege una base de datos. Ejecuta solo los comandos que correspondan a tu despliegue. Revisa y redacta cualquier secreto, y guarda únicamente el inventario mínimo en almacenamiento con acceso restringido; nunca adjuntes salidas crudas al registro del cambio.

Si jq no está disponible, usa pm2 list y registra manualmente solo esos campos. Define criterios de éxito —health check, latencia, errores, trabajos en cola y funciones críticas— y un umbral claro para volver a la imagen o al runtime anterior. El rollback debe ser temporal si devuelve una versión vulnerable.

3. Actualiza con el método que ya administra Node.js

NVM

Elige una versión objetivo: 22.23.2 para 22.x, 24.18.1 para 24.x o 26.5.1 para 26.x. Este ejemplo usa 24.x; cambia TARGET si tu rama es otra. Verifica que el usuario que ejecuta el servicio utiliza la misma instalación NVM.

Un cambio de runtime puede requerir recompilar módulos nativos dentro del pipeline normal de la aplicación. Hazlo desde el lockfile y las instrucciones del proyecto; no conviertas un npm update indiscriminado en parte del parche.

Docker

Las imágenes oficiales pueden publicarse horas después del binario y aparecer por arquitectura de forma gradual, como advierte la documentación de docker-node. Comprueba primero la etiqueta exacta y sus plataformas con docker buildx imagetools inspect. Si devuelve manifest unknown o no matching manifest, detén esta vía: no sustituyas 24.18.1 por 24.18.0 ni otra versión sin el parche.

El Dockerfile debe consumir explícitamente la base comprobada. Una forma segura es declarar ARG BASE_IMAGE antes de FROM ${BASE_IMAGE} y pasar un digest resuelto; también puedes fijar ese digest directamente en FROM. El nombre de la imagen de aplicación no demuestra qué runtime contiene.

La comprobación con docker run --rm valida la imagen construida antes del despliegue y solo elimina ese contenedor efímero de verificación. Los dos comandos docker exec se ejecutan después del despliegue controlado y deben devolver v24.18.1 y la ruta del binario dentro del contenedor. Este ejemplo solo es válido si el Dockerfile usa realmente ARG BASE_IMAGE en FROM; de lo contrario, corrige primero el Dockerfile.

Paquetes de la distribución o del proveedor

Consulta primero la versión candidata. Los repositorios pueden publicar el parche con retraso o usar un número de paquete con backport; valida la documentación del proveedor y no continúes si no puedes demostrar que la candidata contiene las correcciones. Ejecuta únicamente la sección correspondiente a tu sistema.

Para un backport, conserva la versión completa del paquete y el aviso del proveedor que confirma las CVE corregidas; node --version por sí solo no demuestra el backport. No uses apt autoremove ni limpiezas de imágenes o paquetes como parte de esta respuesta. Conserva los artefactos anteriores hasta cerrar la ventana de observación.

4. Reinicia el proceso correcto

Un binario actualizado en disco no cambia un proceso que ya está en memoria. Reinicia o recarga de forma controlada y confirma el estado. Sustituye los nombres de ejemplo por los de tu servicio.

Si PM2 o systemd apunta a una ruta absoluta antigua, corrige el despliegue antes de darlo por terminado. Una shell que muestra la versión nueva no prueba qué binario usa el proceso de producción.

5. Verifica versión, función y telemetría

Comprueba la versión desde cada contexto de ejecución, prueba una ruta funcional y observa errores, reinicios, memoria, CPU, latencia y conexiones. Los comandos son una lista de verificación documentada; adáptalos a tus nombres y endpoints.

• Con NVM, binarios upstream e imágenes oficiales, todos los workers, réplicas y jobs deben mostrar exactamente la versión corregida de su rama.
• Con paquetes de una distribución, registra la versión completa con dpkg-query, rpm -q o apk info -v y conserva el aviso del proveedor que documenta el backport; no declares éxito solo con node --version.
• Ejecuta smoke tests de autenticación, API, tareas programadas, bots, WebSockets, HTTP/2, llamadas TLS/mTLS y SQLite cuando esas funciones existan.
• Compara la ventana posterior con tu línea base: tasa de 5xx, latencia p95/p99, uso de memoria, reinicios, errores TLS/DNS y profundidad de colas.
• Mantén observación suficiente para cubrir al menos un ciclo relevante de tráfico y trabajos programados.

Solución de problemas antes del rollback

• manifest unknown o no matching manifest: confirma etiqueta y plataforma con Buildx. Si la versión corregida aún no está publicada para tu arquitectura, detén la vía Docker y espera esa imagen o usa otro suministro verificable del runtime; no despliegues la etiqueta anterior.
• La shell cambió, pero PM2 o systemd no: comprueba el ejecutable del PID real mediante /proc. Corrige la ruta del intérprete en la configuración versionada y reinicia solo api o myapp.service.
• El paquete candidato no prueba el backport: no actualices a ciegas ni declares éxito. Registra la versión completa y exige un aviso del proveedor que relacione el paquete con estas CVE.
• Falla un módulo nativo: si aparece un error de ABI o NODE_MODULE_VERSION, reconstruye el módulo en CI o staging desde el lockfile y vuelve a desplegar. No uses npm update como atajo en producción.
• Falla el health check: revisa logs y telemetría. Si se supera el umbral definido antes del cambio o una función crítica queda inoperable, activa el rollback correspondiente.

Ejecuta solo la consulta de paquetes correspondiente a tu distribución. Estas comprobaciones diagnostican estado; no sustituyen la validación funcional.

6. Ejecuta rollback solo con un criterio definido

Activa la reversión únicamente si el umbral definido antes del cambio se cumple. Usa los valores exactos registrados y restaura la configuración versionada que corresponde al artefacto anterior. Volver a una versión vulnerable reabre la exposición, por lo que el rollback debe ser temporal y quedar documentado.

NVM y PM2

Restaura primero el archivo de proceso versionado si contiene una ruta de intérprete absoluta. Sustituye el valor de ejemplo por la versión exacta registrada y recarga solo la aplicación afectada.

Docker

Redespliega el digest inmutable de la imagen de aplicación anterior, no el digest de la base Node. Este ejemplo solo aplica si Compose consume la variable APP_IMAGE; en otro orquestador, usa su mecanismo documentado con el mismo digest registrado. Si tu versión de Compose no admite --wait, usa una espera explícita con timeout; no la omitas.

systemd y paquetes del sistema operativo

Restaura la unidad y la configuración anteriores desde su fuente versionada mediante el flujo de despliegue aprobado; después recarga systemd y reinicia únicamente el servicio afectado. Para un paquete del sistema, usa exclusivamente el rollback documentado por el proveedor y solo si conservaste el artefacto exacto; no hagas un downgrade genérico.

Después de cada reversión, comprueba la versión y el ejecutable del proceso real, el health check y la misma telemetría usada como criterio. Documenta la exposición reabierta, mantén mitigaciones parciales y programa la corrección de compatibilidad para reaplicar el parche.

Qué hacer si tu versión está EOL

Node.js indica que las ramas fuera de soporte deben considerarse afectadas cuando ocurre una versión de seguridad. En julio de 2026, 22.x está en Maintenance LTS, 24.x en Active LTS y 26.x en Current; ramas como 20.x ya están EOL según el calendario vigente. No esperes un parche público para una rama EOL.

1. Identifica incompatibilidades de runtime, módulos nativos y dependencias.
2. Elige una rama soportada; para producción, una LTS suele reducir cambios no relacionados.
3. Prueba en staging con datos y tráfico representativos.
4. Despliega por etapas, valida telemetría y conserva un rollback acotado.

Si administras APIs, bots o aplicaciones Next.js, separa la actualización del runtime de las correcciones del framework. Consulta también la guía sobre las vulnerabilidades de Next.js de julio de 2026: actualizar Node.js no reemplaza el parche de Next.js, ni al revés.

Preguntas frecuentes

¿Qué versión de Node.js debo instalar?

Instala 22.23.2 si debes permanecer en 22.x, 24.18.1 si estás en 24.x o 26.5.1 si estás en 26.x. No saltes de rama durante la respuesta urgente salvo que tu versión esté EOL o ya tengas validada la migración.

¿npm update corrige estas CVE?

No. Las CVE enumeradas se corrigen en el runtime Node.js y en dependencias que distribuye el propio runtime, como llhttp y undici. npm administra dependencias de la aplicación; comprobar o actualizar esas dependencias es un trabajo distinto.

¿Estoy protegido si uso un reverse proxy?

No necesariamente. Depende de dónde termina HTTP/2, del protocolo entre el proxy y Node, y de si la aplicación usa las otras superficies afectadas: HTTPS Agent, Permission Model, DNS, zlib, SQLite o lógica de proxy en Node. Verifica la arquitectura y actualiza el runtime.

¿Hay explotación activa o una puntuación CVSS oficial?

Las fuentes oficiales consultadas no confirman explotación activa. El boletín clasifica la severidad como alta, media o baja, pero no incluye puntuaciones CVSS numéricas. Si Node.js publica después CVSS, explotación confirmada o una fe de errata, esta misma URL debe actualizarse con el nuevo dato.

¿Puedo mitigar sin reiniciar?

Algunas medidas reducen exposición, como retirar HTTP/2 si no se usa o separar agentes por identidad. No corrigen el binario. Programa el reinicio controlado necesario para cargar la versión parcheada.

¿La actualización garantiza que mi servicio funciona?

No. La versión corregida elimina los fallos descritos, pero la compatibilidad de tu aplicación debe validarse con smoke tests y telemetría. Los comandos de esta guía son instrucciones documentadas; no representan pruebas ejecutadas por Teramont en tu servicio.

Conclusión

La alerta dejó de ser preventiva: los parches ya existen. Actualiza a 22.23.2, 24.18.1 o 26.5.1 según tu rama, verifica el binario dentro del proceso o contenedor real y conserva un rollback trazable.

Fuentes primarias

• Node.js: Wednesday, July 29, 2026 Security Releases
• Node.js 22.23.2 (LTS)
• Node.js 24.18.1 (LTS)
• Node.js 26.5.1 (Current)
• Índice oficial de distribuciones de Node.js
• Node.js Release Working Group: calendario de versiones