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
--permissioncuando 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
| Rama | Estado al 29-jul-2026 | Versión corregida | Dependencias incluidas | Acción recomendada |
|---|---|---|---|---|
| 22.x | Maintenance LTS | 22.23.2 LTS | llhttp 9.4.3; undici 6.28.0 | Actualizar a 22.23.2 y planificar el salto a una LTS más reciente según compatibilidad. |
| 24.x | Active LTS | 24.18.1 LTS | llhttp 9.4.3; undici 7.29.0 | Actualizar a 24.18.1 y mantener la rama 24 en el ciclo habitual. |
| 26.x | Current | 26.5.1 Current | llhttp 9.4.3; undici 8.9.0 | Actualizar a 26.5.1; confirmar compatibilidad porque Current cambia con mayor frecuencia. |
| EOL | Sin soporte público | No hay parche en esa rama | No aplica | Migrar a una rama soportada, preferiblemente LTS para producción. |
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
| CVE | Severidad oficial | Componente | Impacto práctico | Ramas afectadas |
|---|---|---|---|---|
| CVE-2026-56846 | Alta | HTTP/2 | Cabeceras retenidas pueden eludir maxSessionMemory y agotar memoria de forma remota. | 22.x, 24.x; no 26.x |
| CVE-2026-56848 | Alta | HTTP/2 / nghttp2 | Un envío reentrante puede provocar un heap-use-after-free durante el procesamiento HTTP/2. | 22.x, 24.x, 26.x |
| CVE-2026-58043 | Alta | Permission Model | El emparejamiento por prefijos del árbol radix puede conceder lectura o escritura fuera de la ruta permitida. | 22.x, 24.x, 26.x |
| CVE-2026-56850 | Media | HTTPS Agent / mTLS | Colisiones en claves de arreglos PFX pueden reutilizar una identidad cliente entre solicitudes con certificados distintos. | 22.x, 24.x, 26.x |
| CVE-2026-58040 | Media | HTTPS Agent / TLS | La reutilización de sesiones TLS puede omitir la verificación de hostname entre políticas de identidad. | 22.x, 24.x, 26.x |
| CVE-2026-58041 | Media | node:sqlite / SQLTagStore | Un iterador obsoleto puede volver a ejecutar escrituras después de resetear y reenlazar una sentencia preparada. | 24.x, 26.x; no 22.x |
| CVE-2026-58042 | Media | DNS | dns.resolveAny() puede abortar el proceso ante una respuesta con más de 256 registros A, causando denegación de servicio. | 22.x, 24.x, 26.x |
| CVE-2026-58045 | Media | node:zlib | Una longitud TypedArray falsificada puede alcanzar una aserción y hacer caer las API síncronas de zlib. | 22.x, 24.x, 26.x |
| CVE-2026-56847 | Baja | Permission Model / trace events | Los eventos de traza pueden escribir registros fuera de las rutas autorizadas por --allow-fs-write. | 22.x, 24.x, 26.x |
| CVE-2026-58039 | Baja | Permission Model / process.report | Los informes de proceso pueden escribir o sobrescribir fuera de la lista de rutas permitidas. | 22.x, 24.x, 26.x |
| CVE-2026-58044 | Baja | Cliente HTTP / proxies | La truncación de cabeceras puede desincronizar solicitudes en proxies Node que reconstruyen cabeceras y canalizan el cuerpo a conexiones backend reutilizadas. | 22.x, 24.x, 26.x |
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:
- 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.
- 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.
- 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.
node:sqlitecon SQLTagStore: 58041 solo aplica a 24.x y 26.x. Revisa flujos de escritura e idempotencia durante la validación.- 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. - Objetos pasados a las API síncronas de zlib: 58045 requiere que se pueda influir en el objeto o en la longitud
TypedArrayentregada a la API. El boletín no afirma que cualquier archivo comprimido externo baste para activar el fallo. - 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.
node --version
node -p process.execPath
node -p 'JSON.stringify(process.versions)'
command -v node
npm --version
pm2 list
systemctl list-units --type=service --state=running
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'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.
node --version > node-version.before.txt
node -p process.execPath > node-path.before.txt
npm ls --depth=0 > npm-tree.before.txt 2>&1
pm2 jlist | jq '[.[] | {name, pid, status: .pm2_env.status, exec_interpreter: .pm2_env.exec_interpreter, pm_exec_path: .pm2_env.pm_exec_path, node_version: .pm2_env.node_version}]' > pm2-processes.before.json
systemctl show myapp.service -p User -p ExecStart -p FragmentPath -p EnvironmentFiles > systemd-metadata.before.txt
docker image inspect myapp:current --format '{{.Id}}' > docker-image-id.before.txt
docker image inspect myapp:current --format '{{json .RepoDigests}}' > docker-image-digests.before.jsonSi 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.
TARGET=24.18.1
nvm install $TARGET
nvm use $TARGET
nvm alias default $TARGET
node --version
node -p process.execPathUn 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.
set -euo pipefail
TARGET_TAG='node:24.18.1-bookworm-slim'
docker buildx imagetools inspect "$TARGET_TAG"
docker pull "$TARGET_TAG"
BASE_IMAGE=$(docker image inspect "$TARGET_TAG" --format '{{index .RepoDigests 0}}')
test -n "$BASE_IMAGE"
docker buildx imagetools inspect "$BASE_IMAGE"
docker build --pull --build-arg BASE_IMAGE="$BASE_IMAGE" -t myapp:node-24.18.1 .
docker run --rm --entrypoint node myapp:node-24.18.1 --version
docker exec api node --version
docker exec api node -p process.execPathLa 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.
# Debian o Ubuntu: inspección y actualización del paquete candidato
apt-cache policy nodejs
sudo apt-get update
apt-cache policy nodejs
sudo apt-get install --only-upgrade nodejs
dpkg-query -W -f='${Package} ${Version}\n' nodejs
# Fedora, RHEL o derivados: inspección y actualización
sudo dnf check-update nodejs
sudo dnf upgrade nodejs
rpm -q nodejs
# Alpine: inspección y actualización
apk policy nodejs
sudo apk update
sudo apk upgrade nodejs
apk info -v nodejs
node --versionPara 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.
Actualiza Node.js con control sobre tu entorno
Planifica el cambio de runtime en un entorno que administras, con verificación de versión y un rollback definido.
# PM2
pm2 describe api
pm2 reload ecosystem.config.js --only api --update-env
pm2 list
pm2 logs --lines 100 --nostream
# systemd
systemctl show myapp.service -p User -p ExecStart -p FragmentPath -p EnvironmentFiles
sudo systemctl restart myapp.service
sudo systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service --since=-10min --no-pagerSi 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.
node --version
curl -fsS http://127.0.0.1:3000/health
pm2 describe api
pm2 logs --lines 100 --nostream
sudo systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service --since=-10min --no-pager
docker exec api node --version
docker exec api node -p 'JSON.stringify(process.versions)'- 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 -qoapk info -vy conserva el aviso del proveedor que documenta el backport; no declares éxito solo connode --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 unknownono 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 soloapiomyapp.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 usesnpm updatecomo 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.
TARGET_TAG='node:24.18.1-bookworm-slim'
docker buildx imagetools inspect "$TARGET_TAG"
mapfile -t PM2_PIDS < <(pm2 jlist | jq -er '.[] | select(.name == "api" and .pm2_env.status == "online") | .pid')
((${#PM2_PIDS[@]} > 0)) || { printf 'no hay procesos PM2 online llamados api\n' >&2; exit 1; }
for PM2_PID in "${PM2_PIDS[@]}"; do
PM2_NODE=$(readlink -f "/proc/$PM2_PID/exe")
test -x "$PM2_NODE"
printf 'PID %s -> %s\n' "$PM2_PID" "$PM2_NODE"
"$PM2_NODE" --version
done
SYSTEMD_PID=$(systemctl show myapp.service -p MainPID --value)
readlink -f "/proc/$SYSTEMD_PID/exe"
dpkg-query -W -f='${Package} ${Version}\n' nodejs
rpm -q nodejs
apk info -v nodejsEjecuta 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.
set -euo pipefail
PREVIOUS_NODE='REEMPLAZA_CON_VERSION_REGISTRADA'
if [[ "$PREVIOUS_NODE" == *REEMPLAZA* ]]; then
printf 'PREVIOUS_NODE debe ser una versión semver exacta\n' >&2
exit 1
fi
if [[ ! "$PREVIOUS_NODE" =~ ^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$ ]]; then
printf 'PREVIOUS_NODE debe ser una versión semver exacta\n' >&2
exit 1
fi
nvm use "$PREVIOUS_NODE"
pm2 reload ecosystem.config.js --only api --update-env
mapfile -t PM2_PIDS < <(pm2 jlist | jq -er '.[] | select(.name == "api" and .pm2_env.status == "online") | .pid')
((${#PM2_PIDS[@]} > 0)) || { printf 'no hay procesos PM2 online llamados api\n' >&2; exit 1; }
for PM2_PID in "${PM2_PIDS[@]}"; do
PM2_NODE=$(readlink -f "/proc/$PM2_PID/exe")
test -x "$PM2_NODE"
PM2_VERSION=$("$PM2_NODE" --version)
test "$PM2_VERSION" = "v$PREVIOUS_NODE"
printf 'PID %s -> %s (%s)\n' "$PM2_PID" "$PM2_NODE" "$PM2_VERSION"
done
pm2 describe api
curl -fsS http://127.0.0.1:3000/healthDocker
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.
set -euo pipefail
PREVIOUS_APP_IMAGE='REEMPLAZA_CON_IMAGEN_Y_DIGEST_REGISTRADOS'
if [[ "$PREVIOUS_APP_IMAGE" == *REEMPLAZA* ]]; then
printf 'PREVIOUS_APP_IMAGE debe ser una referencia con digest sha256\n' >&2
exit 1
fi
if [[ ! "$PREVIOUS_APP_IMAGE" =~ ^[^[:space:]]+@sha256:[0-9a-fA-F]{64}$ ]]; then
printf 'PREVIOUS_APP_IMAGE debe ser una referencia con digest sha256\n' >&2
exit 1
fi
docker buildx imagetools inspect "$PREVIOUS_APP_IMAGE"
docker pull "$PREVIOUS_APP_IMAGE"
EXPECTED_IMAGE_ID=$(docker image inspect "$PREVIOUS_APP_IMAGE" --format '{{.Id}}')
APP_IMAGE="$PREVIOUS_APP_IMAGE" docker compose up --no-deps --wait --wait-timeout 120 api
mapfile -t RUNNING_CONTAINER_IDS < <(docker compose ps -q --all api)
((${#RUNNING_CONTAINER_IDS[@]} > 0)) || { printf 'no containers found for api\n' >&2; exit 1; }
for RUNNING_CONTAINER_ID in "${RUNNING_CONTAINER_IDS[@]}"; do
RUNNING_STATE=$(docker inspect "$RUNNING_CONTAINER_ID" --format '{{.State.Running}}')
test "$RUNNING_STATE" = 'true'
RUNNING_IMAGE_ID=$(docker inspect "$RUNNING_CONTAINER_ID" --format '{{.Image}}')
test "$RUNNING_IMAGE_ID" = "$EXPECTED_IMAGE_ID"
docker exec "$RUNNING_CONTAINER_ID" node --version
done
curl -fsS http://127.0.0.1:3000/healthsystemd 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.
set -euo pipefail
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
SYSTEMD_PID=$(systemctl show myapp.service -p MainPID --value)
if [[ ! "$SYSTEMD_PID" =~ ^[1-9][0-9]*$ ]]; then
printf 'myapp.service no tiene un MainPID válido\n' >&2
exit 1
fi
SYSTEMD_NODE=$(readlink -f "/proc/$SYSTEMD_PID/exe")
test -x "$SYSTEMD_NODE"
printf 'PID %s -> %s\n' "$SYSTEMD_PID" "$SYSTEMD_NODE"
"$SYSTEMD_NODE" --version
sudo systemctl status myapp.service --no-pager
curl -fsS http://127.0.0.1:3000/healthDespué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.
- Identifica incompatibilidades de runtime, módulos nativos y dependencias.
- Elige una rama soportada; para producción, una LTS suele reducir cambios no relacionados.
- Prueba en staging con datos y tráfico representativos.
- 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.