Node.js publicó el 21 de octubre de 2026 una actualización de seguridad para sus ramas 22, 24 y 26. Si ejecutas una API, una web con renderizado en servidor o un bot, revisa el Node.js que utiliza cada servicio, no solo el instalado en tu terminal. Los parches oficiales son 22.23.4, 24.22.1 y 26.12.1.
El aviso del proyecto enumera 10 CVEs: cuatro de gravedad alta, tres media y tres baja. No ofrece una cifra global de sistemas atacados. Tener una versión afectada no demuestra que alguien haya comprometido tu servidor.
Qué versión de Node.js debes instalar
Para un despliegue existente, empieza por el parche de tu misma rama y valida compatibilidad. No necesitas saltar de 22 a 26 para recibir estas correcciones. Si tu versión está fuera de soporte, planifica la migración a una rama mantenida: no aparecer en esta tabla no la convierte en segura.
Esta referencia corresponde a los binarios oficiales del proyecto. Si tu distribución mantiene un paquete con parches retroportados, solicita el aviso de seguridad y la versión exacta del paquete corregido; comparar únicamente el número mostrado por Node puede resultar insuficiente.
Los 10 CVEs: alcance confirmado
La tabla resume el boletín y las notas de las tres versiones enlazadas arriba. Las ramas indican dónde informa el proyecto que existe el problema; no significan que todas las aplicaciones utilicen la función vulnerable. Para la gravedad individual seguimos el boletín, que distingue los dos CVEs TLS agrupados en las notas de lanzamiento.
| CVE | Problema y gravedad | Ramas |
|---|---|---|
| CVE-2026-105482 | DNS: nombres truncados por un carácter NUL. Alta. | 22, 24, 26 |
| CVE-2026-105483 | TLS: validación del nombre con dígitos de ancho completo. Alta. | 24, 26 |
| CVE-2026-106069 | TLS: validación incorrecta al interpretar un host como IP. Alta. | 22, 24, 26 |
| CVE-2026-111497 | Brotli: escritura fuera de límites; posible ejecución remota de código. Alta. | 22, 24, 26 |
| CVE-2026-105481 | HTTP keep-alive: aceptación de una respuesta anterior a la petición. Media. | 22, 24, 26 |
| CVE-2026-106072 | TLS: IPv4 no canónica autenticada mediante nombres DNS del certificado. Media. | 22, 24, 26 |
| CVE-2026-106074 | Cachés aleatorias repetidas mediante snapshots de arranque o SEA. Media. | 22, 24, 26 |
| CVE-2026-106070 | ZipFile: devolución de bytes tras rechazar una cabecera ZIP. Baja. | 26 |
| CVE-2026-106071 | Permission Model: permisos de archivos excesivos con comodines. Baja. | 26 |
| CVE-2026-106073 | Permission Model: omisión de comprobación en fs.realpathSync. Baja. | 22, 24, 26 |
Qué significa para una web, API o bot en un VPS
Nuestra recomendación es actualizar todos los servicios de las ramas afectadas y priorizar los que procesan entradas externas. Para ordenar el trabajo, estas preguntas son más útiles que intentar deducir el riesgo solo por el framework:
- ¿Descomprimes contenido Brotli recibido de terceros? Revisa dónde llegan esos datos al decodificador de Node. El fallo de memoria merece prioridad, pero el aviso no demuestra que cualquier petición HTTP explote automáticamente cualquier aplicación.
- ¿Tu aplicación hace conexiones HTTPS salientes? Incluye pagos, webhooks y consultas a otras API en las pruebas posteriores. Un certificado correcto en la entrada de tu proxy no comprueba cómo Node valida los destinos a los que se conecta.
- ¿Distribuyes snapshots de arranque o aplicaciones SEA? Son artefactos con estado de inicio o ejecutables empaquetados. Revisa su reconstrucción, además del runtime. Un snapshot de arranque de Node no es un snapshot de disco del VPS.
- ¿Usas Permission Model? Actualiza también esos procesos. La documentación de Node.js aclara que esta función no es una barrera para ejecutar código malicioso con seguridad.
El alcance de un eventual compromiso depende de los permisos del proceso y de los recursos a los que accede. Como defensa adicional, ejecuta la aplicación sin privilegios de administrador y limita sus credenciales. Estas medidas reducen exposición; no sustituyen el parche.
Cómo comprobar tu versión sin lanzar un ataque de prueba
Estos comandos son de diagnóstico. No explotan las vulnerabilidades ni prueban que un servidor esté limpio:
node --version
node -p 'JSON.stringify({node:process.version,execPath:process.execPath,openssl:process.versions.openssl},null,2)'
El primer resultado identifica la versión; el segundo añade la ruta del ejecutable y el OpenSSL de ese proceso. Solo describen el Node que acaba de iniciar tu shell. Un servicio systemd, un usuario distinto o PM2 pueden arrancar otro binario.
Con Docker, sustituye NOMBRE_CONTENEDOR por un contenedor de tu aplicación:
Tu API o bot, en un VPS con mantenimiento claro
Compara los VPS de TERAMONT para tu proyecto. Define quién administra el runtime, despliega los parches y comprueba cada servicio.
docker exec NOMBRE_CONTENEDOR node --version
Eso comprueba el ejecutable disponible dentro de ese contenedor, no demuestra que un worker antiguo se haya reiniciado. Registra la versión al arrancar la aplicación, en un log interno, con un fragmento como este:
console.info('runtime-start', {
node: process.version,
execPath: process.execPath,
pid: process.pid
});
Después del despliegue, busca la entrada nueva de cada réplica o worker. No expongas estas rutas mediante un endpoint público de diagnóstico. La referencia de process documenta los campos utilizados.
Actualizar sin dejar procesos antiguos ejecutándose
- Inventaría los puntos de ejecución. API, web, workers, bots, tareas programadas, contenedores y compilaciones de CI. Apunta responsable, versión, origen de instalación y cómo se reinicia cada uno.
- Prepara el cambio. Conserva configuración y datos necesarios para recuperar el servicio. Prueba el parche con tus pruebas habituales; no conviertas una actualización de seguridad en un cambio simultáneo de framework y dependencias sin necesidad.
- Instala desde el canal que administra ese runtime. Usa las descargas oficiales o el paquete corregido de tu proveedor. Si usas imágenes, actualiza la base, reconstruye y despliega la nueva imagen. Cambiar Node en el host no actualiza el contenedor.
- Activa el binario corregido. Reinicia o reemplaza los procesos con el procedimiento de tu gestor. En PM2 o systemd, verifica la ruta del intérprete. En un despliegue con réplicas, comprueba que no quede una instancia antigua recibiendo tráfico.
- Valida y guarda evidencia. Versión en el arranque, imagen o paquete desplegado, fecha y pruebas funcionales de rutas importantes. Revisa errores TLS, conexiones salientes y tareas en segundo plano.
Ejemplo hipotético: actualizas una API y su terminal muestra 24.22.1, pero un worker usa una imagen anterior. El trabajo no está terminado aunque la página principal cargue. La comprobación debe cubrir ambos procesos.
Esta actualización también aborda el incidente de eMudhra
Las notas de Node.js 22.23.4 incluyen certificados raíz de NSS 3.131.1 y el rechazo de cadenas con claves públicas bloqueadas; las otras dos ramas también incorporan cambios de confianza. Es otra razón para revisar las conexiones HTTPS después del despliegue. Un almacén de CA personalizado requiere su propia revisión; no desactives la verificación TLS para ocultar errores.
Dudas antes de cerrar la actualización
¿npm audit o npm update corrigen el runtime?
No. npm audit revisa dependencias; un informe sin alertas no certifica la seguridad del ejecutable Node.js. Actualizar paquetes del proyecto y actualizar el runtime son tareas distintas.
¿Cambiar de VPS o actualizar el kernel lo resuelve?
No por sí solo. Aquí importa qué Node ejecuta tu aplicación. Pide a tu proveedor que aclare qué capa administra y qué debes mantener tú. No presupongas que el proveedor actualizó tus contenedores o instalaciones por usuario.
¿Cómo sé si ya me atacaron?
La versión sirve para identificar una actualización pendiente, no para confirmar una intrusión. Si encuentras procesos desconocidos, cambios no autorizados o accesos anómalos, conserva registros y activa la respuesta a incidentes. Actualizar no elimina por sí mismo una persistencia previa.
Infraestructura con un mantenimiento definido
Si necesitas alojar tu API o bot, compara los planes de VPS Hosting de TERAMONT. Define desde el inicio quién instala Node, quién despliega los parches y quién verifica los procesos. Si estás empezando, consulta qué es un VPS y para qué sirve. El criterio para cerrar este aviso es una versión corregida ejecutándose y comprobada, no solo una instalación descargada.
