Node.js publicará nuevas versiones de seguridad para las ramas 22.x, 24.x y 26.x el lunes 27 de julio de 2026, o poco después. El aviso previo del proyecto confirma que el problema de mayor severidad que se corregirá es de nivel alto en las tres ramas.
La actualización todavía no está disponible. Al 25 de julio, Node.js no ha revelado los CVE, los componentes afectados, las versiones exactas que recibirán el parche ni detalles técnicos de explotación. Esta ventana previa sirve para identificar servidores, preparar pruebas y reservar un momento de mantenimiento, no para especular sobre una vulnerabilidad que aún permanece bajo divulgación coordinada.
Resumen: si ejecutas aplicaciones, APIs, bots, paneles o herramientas de compilación con Node.js 22, 24 o 26, prepara el proceso de actualización. Si continúas en una versión EOL, planifica la migración a una rama con soporte porque el proyecto advierte que las versiones fuera de ciclo también se consideran afectadas y no reciben correcciones públicas.
¿Qué anunció exactamente Node.js?
El aviso oficial de seguridad de Node.js, actualizado el 21 de julio, establece cuatro datos verificables:
- Se publicarán nuevas versiones para Node.js 26.x, 24.x y 22.x.
- La fecha prevista es el 27 de julio de 2026 o poco después.
- La severidad máxima de los problemas corregidos será alta en cada una de las tres ramas.
- Las versiones End-of-Life también se consideran afectadas cuando ocurre una actualización de seguridad.
El anuncio no llama “crítica” a la vulnerabilidad y tampoco confirma explotación activa. Hasta que aparezcan el boletín completo, las notas de versión y los CVE, cualquier afirmación sobre el vector de ataque, el módulo vulnerable o el impacto concreto sería especulación.
Ramas de Node.js involucradas
| Rama | Estado al 25 de julio | Fin de soporte previsto | Acción recomendada |
|---|---|---|---|
| 26.x | Current | 30 de abril de 2029 | Instalar la versión corregida cuando se publique. |
| 24.x | Active LTS | 30 de abril de 2028 | Preparar pruebas y actualización prioritaria. |
| 22.x | Maintenance LTS | 30 de abril de 2027 | Aplicar el parche o planificar migración a 24.x. |
| 20.x y anteriores | EOL | Finalizado | Migrar a una rama soportada; no habrá parche público para la rama EOL. |
El calendario del Node.js Release Working Group clasifica 24.x como Active LTS, 22.x como Maintenance LTS y 26.x como Current. La documentación del proyecto recomienda utilizar ramas Active LTS o Maintenance LTS en aplicaciones de producción.
Qué se sabe y qué todavía no se sabe
Información confirmada
- Hay una actualización coordinada para las tres ramas con soporte.
- La severidad máxima anunciada es alta.
- Los binarios se esperan el 27 de julio o poco después.
- Las instalaciones EOL necesitan migrar, no esperar un parche para su rama.
Información pendiente
- Números CVE y puntuaciones CVSS.
- Versiones exactas afectadas y corregidas.
- Subsistemas, APIs o configuraciones involucradas.
- Mitigaciones específicas o cambios de compatibilidad.
- Evidencia de explotación activa.
Por ahora no existe una mitigación técnica específica que pueda reemplazar el parche. Rate limiting, aislamiento de procesos, firewall y monitoreo siguen siendo controles útiles, pero no corrigen una falla desconocida dentro del runtime.
Checklist antes del 27 de julio
1. Identifica la versión instalada
Ejecuta estas comprobaciones en cada servidor, contenedor, runner de CI y entorno de compilación:
node --version
npm --version
command -v node
node -p "process.execPath"
npm update no actualiza el runtime de Node.js. La versión relevante es la que devuelve node --version en el proceso que realmente ejecuta la aplicación.
2. Localiza procesos y contenedores
ps -eo pid,user,cmd | grep '[n]ode'
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i node
pm2 list
No todos los comandos aplicarán a todos los servidores. La meta es descubrir instalaciones olvidadas: bots gestionados con PM2, imágenes Docker antiguas, runners, tareas cron, paneles y herramientas de build.
3. Prepara respaldo y reversión
- Respalda código, lockfiles, variables de entorno, archivos persistentes y base de datos.
- Si administras un VPS, crea un snapshot antes del cambio.
- Conserva la imagen de contenedor o el artefacto anterior para poder revertir.
- Documenta la versión actual y la versión que instalarás.
4. Define las pruebas mínimas
Antes del despliegue enumera las rutas, WebSockets, tareas en segundo plano, conexiones TLS, cargas de archivos y funciones críticas que deben probarse. Revisa también módulos nativos porque pueden requerir recompilación al cambiar de versión del runtime.
Cómo actualizar cuando se publiquen los parches
Primero consulta el aviso final de Node.js y anota la versión corregida para tu rama. No copies números de versiones de fuentes secundarias antes de que aparezcan en nodejs.org.
Con un administrador de versiones
Si utilizas NVM y deseas permanecer en la rama 24.x, estos comandos instalarán la versión más reciente disponible de esa rama. Ejecútalos después de confirmar que el parche ya fue publicado:
nvm install 24
nvm use 24
nvm alias default 24
node --version
Prepara tu entorno Node.js con control total
Ejecuta tus aplicaciones en un VPS con acceso root, recursos escalables y libertad para actualizar el runtime en cuanto se publiquen los parches.
Sustituye 24 por 22 o 26 únicamente si esa es la rama que decidiste mantener. Para producción general, evalúa una rama LTS compatible con tu aplicación.
En Docker
No basta con reiniciar el contenedor existente: debes descargar una imagen que incluya el runtime corregido y reconstruir tu aplicación.
docker pull node:24-bookworm-slim
docker compose build --pull --no-cache
docker compose up -d
docker compose ps
Comprueba en el registro de la imagen que la etiqueta ya contiene la versión corregida. Para despliegues reproducibles, fija después una versión exacta o un digest en lugar de depender indefinidamente de una etiqueta móvil.
Con paquetes del sistema operativo
Los repositorios de una distribución o de un proveedor pueden publicar el paquete después del lanzamiento oficial. Actualiza el índice, revisa la versión candidata y confirma el resultado tras instalar. No asumas que ejecutar una actualización general garantiza que el binario corregido ya llegó al repositorio.
Reinicia el proceso correcto
pm2 restart all
pm2 status
sudo systemctl restart mi-aplicacion
sudo systemctl status mi-aplicacion --no-pager
Usa solo el administrador que corresponda a tu despliegue. Si el servicio carga Node.js desde una ruta diferente a tu sesión de shell, verifica el ejecutable configurado en systemd, PM2 o el contenedor.
Validación después de actualizar
node --version
npm test
npm run build
curl -I https://tu-dominio.example
Además de confirmar la versión, observa errores HTTP, latencia, consumo de CPU y memoria, reinicios del proceso y fallos en módulos nativos. Mantén disponible el rollback hasta completar las pruebas y revisar los primeros minutos de tráfico real.
¿Qué hacer si usas Node.js 20 o una versión anterior?
Node.js 20 aparece como EOL en la página oficial de versiones. El anuncio de julio recuerda que las ramas fuera de soporte se consideran afectadas cuando ocurre un lanzamiento de seguridad, pero no reciben nuevas compilaciones públicas. En ese escenario, la solución sostenible es migrar a una rama soportada.
Una migración entre versiones mayores requiere probar dependencias, módulos nativos, APIs obsoletas y cambios del motor V8. Si no puedes completarla antes del 27 de julio, reduce temporalmente la exposición del servicio, refuerza los límites del proxy y acelera la migración; esas medidas disminuyen riesgo operativo, pero no convierten una rama EOL en segura.
Recomendaciones para Node.js en un VPS
- Ejecuta la aplicación con un usuario sin privilegios.
- Expón únicamente Nginx, Caddy u otro proxy inverso; no publiques el puerto interno de Node.js sin necesidad.
- Limita puertos con firewall y aplica rate limiting donde tenga sentido.
- Guarda secretos fuera del repositorio y rota credenciales si existe evidencia de compromiso.
- Supervisa CPU, memoria, respuestas 5xx y reinicios del proceso.
- Automatiza alertas de nuevas versiones sin desplegar a producción sin pruebas.
Si administras una aplicación Node.js en infraestructura propia, los VPS de Teramont Host permiten controlar el runtime, el sistema operativo, el proxy y las ventanas de actualización. El parcheo de la aplicación sigue siendo responsabilidad del administrador, pero contar con snapshots y recursos dedicados facilita probar y revertir cambios.
Node.js también forma parte de muchos despliegues de Next.js. Si utilizas ambos, revisa nuestra guía sobre las nueve vulnerabilidades corregidas en Next.js 16.2.11 y 15.5.21: actualizar Next.js no sustituye la actualización del runtime de Node.js, ni al revés.
Preguntas frecuentes
¿Ya están disponibles los parches de Node.js?
No al momento de redactar este artículo el 25 de julio. El proyecto espera publicarlos el 27 de julio de 2026 o poco después.
¿Cuáles son los CVE?
Todavía no se han publicado. El aviso previo solo confirma las ramas involucradas y una severidad máxima alta.
¿Existe explotación activa?
El aviso oficial no reporta explotación activa. La ausencia de una confirmación pública no permite concluir que el riesgo sea cero, pero tampoco justifica afirmar que existen ataques en curso.
¿Ejecutar npm update corrige la vulnerabilidad?
No. npm update actualiza dependencias del proyecto dentro de los límites configurados, pero no reemplaza el binario de Node.js. Debes actualizar el runtime mediante el método con el que fue instalado.
¿Debo cambiar inmediatamente de Node.js 22 a 24?
No necesariamente. Node.js 22 todavía está en Maintenance LTS y recibirá una versión corregida. Sin embargo, conviene planificar la migración a 24.x antes de que 22.x llegue al final de su soporte.
¿Una actualización de Next.js también actualiza Node.js?
No. Son componentes distintos. Next.js se instala como dependencia del proyecto; Node.js es el runtime que ejecuta la aplicación.
Conclusión
La alerta del 27 de julio no exige entrar en pánico, pero sí preparar el terreno. Haz un inventario de tus versiones de Node.js, identifica contenedores y procesos, crea respaldos, define pruebas y reserva una ventana de mantenimiento. Cuando Node.js publique los CVE y las compilaciones corregidas, verifica la versión oficial, actualiza, reconstruye tus artefactos y supervisa el despliegue.
Este artículo deberá actualizarse cuando aparezca el boletín final para incorporar versiones corregidas, CVE, severidad detallada, mitigaciones y cualquier evidencia oficial de explotación.
