Node.js es una de las tecnologías más usadas para construir la parte de atrás de una aplicación: lo que procesa pagos, guarda datos y conecta servicios. En HitOcean la usamos en muchos de los proyectos que desarrollamos para nuestros clientes. Por eso seguimos de cerca cada aviso de seguridad, y 2026 vino cargado.
Hubo dos frentes. Por un lado, el propio Node.js corrigió 50 fallas de seguridad en cinco tandas de parches. Por otro, npm, el lugar del que los proyectos descargan las piezas de código que usan, sufrió varios ataques a la cadena de suministro, el más grande con más de 440 paquetes infectados. Aquí te contamos qué pasó, qué versiones ya no tienen soporte y qué revisamos nosotros en cada proyecto.
¿Qué es un ataque a la cadena de suministro?
Ningún software se escribe de cero. Un proyecto Node.js típico usa cientos de librerías hechas por otras personas: una para fechas, otra para conectarse a la base de datos, otra para leer archivos. Y cada una de esas librerías usa otras. Esa red de piezas ajenas es la cadena de suministro del software.
Un ataque a la cadena de suministro aprovecha esa confianza. En lugar de atacar tu sistema, el atacante toma el control de una de esas piezas y le agrega código malicioso. Cuando tu equipo actualiza o instala dependencias, ese código entra solo, con todos los permisos de tu proyecto.
Es la misma lógica que vimos en el hackeo a Binance por ingeniería social: el atacante no rompe la puerta, consigue que alguien de adentro la abra sin darse cuenta.
Los ataques a npm de 2026
- Mayo, node-ipc. Alguien publicó tres versiones con código malicioso de esta librería, que tiene más de 10 millones de descargas por semana. Salieron desde una cuenta de mantenedor sin historial en el paquete.
- Mayo, paquetes falsos. Aparecieron 45 paquetes con nombres que imitaban los paquetes internos de nueve organizaciones reales, según Microsoft. Es lo que se llama “confusión de dependencias”: el proyecto instala el paquete falso creyendo que es el propio.
- Agosto, keyv. Un gusano, un programa que se copia solo, entró por la cuenta de GitHub del mantenedor de keyv y se fue pasando a otros paquetes. Llegó a más de 440 paquetes y 1.381 versiones, que suman más de 2.000 millones de instalaciones por mes.
Los detalles están en los informes de StepSecurity sobre node-ipc, de Microsoft sobre la confusión de dependencias y de Aikido sobre keyv.
Los tres casos tienen algo en común: el objetivo eran las llaves, no los datos de la aplicación. El código malicioso buscaba tokens de npm y GitHub, claves de la nube, contraseñas de bases de datos y archivos de configuración. Con esas llaves, el atacante puede publicar nuevas versiones infectadas o entrar a la infraestructura de la empresa.
Hay un detalle del caso keyv que nos parece clave. Las versiones infectadas salieron por el proceso automático de publicación del propio proyecto, así que llevaban la firma que indica que el paquete viene del repositorio oficial. La firma era real. El problema era que el atacante ya controlaba la cuenta. Que un paquete venga del lugar correcto no garantiza que sea seguro.
Las 50 fallas que corrigió Node.js en 2026
Además de los paquetes de terceros, el propio Node.js publicó cinco tandas de parches de seguridad este año, según su blog oficial de vulnerabilidades:
| Fecha | Fallas corregidas | Graves |
|---|---|---|
| 13 de enero | 8 | 3 |
| 24 de marzo | 9 | 2 |
| 18 de junio | 12 | 2 |
| 29 de julio | 11 | 3 |
| 21 de octubre | 10 | 4 |
Y ya hay una sexta anunciada para el 11 de noviembre, que va a corregir al menos una falla grave en las versiones 22, 24 y 26.
No hace falta entender cada falla para ver el patrón. Muchas permitían tumbar un servidor con un pedido armado a propósito: en marzo, por ejemplo, bastaba con mandar un encabezado llamado __proto__ para que la aplicación se cayera (CVE-2026-21710). Otras afectaban la verificación de certificados, la parte que confirma que te conectas con quien dices conectarte. Y la más seria de octubre, en el descompresor de archivos Brotli, podía llegar a permitir que un atacante ejecute código propio en el servidor (CVE-2026-111497).
Un CVE es el número de identificación que recibe cada falla de seguridad publicada, para que todos hablen de la misma.
Las versiones de Node.js que ya no tienen soporte
Este es el punto que más vemos descuidado en proyectos que nos llegan para mantener. Cada versión de Node.js recibe parches durante un tiempo y después queda sola. Según el calendario oficial de versiones:
| Versión | Estado en noviembre de 2026 |
|---|---|
| Node.js 18 | Sin soporte desde el 30 de abril de 2025 |
| Node.js 20 | Sin soporte desde el 30 de abril de 2026 |
| Node.js 25 | Sin soporte desde el 1 de junio de 2026 |
| Node.js 22 | Con parches hasta el 30 de abril de 2027 |
| Node.js 24 | Con parches hasta el 30 de abril de 2028 |
| Node.js 26 | Con parches hasta el 30 de abril de 2029 |
Node.js lo dice en cada aviso: cuando sale una tanda de parches, las versiones sin soporte están siempre afectadas y no reciben el arreglo. Si tu aplicación sigue en Node.js 20, las fallas de junio, julio y octubre siguen abiertas en tu servidor.
Qué revisamos en HitOcean en cada proyecto Node.js
Esto es lo que hacemos en los proyectos que desarrollamos y mantenemos, y lo que te recomendamos revisar en el tuyo:
- La versión de Node.js. Que el proyecto corra en una versión con soporte y que haya una fecha planificada para el próximo salto. Hoy, quien está en la 22 ya debería tener en agenda pasar a la 24.
- Versiones exactas de cada dependencia. El archivo de bloqueo del proyecto (
package-lock.json) se guarda y se respeta. Así nadie instala por sorpresa una versión que salió ayer. - No actualizar el mismo día. La mayoría de los paquetes infectados se detectan en horas o pocos días. Esperar antes de adoptar una versión nueva reduce mucho el riesgo.
- Scripts de instalación bajo control. El gusano de keyv y los paquetes falsos de mayo se ejecutaban apenas se instalaban. Desactivar esos scripts cuando no hacen falta corta ese camino.
- Tokens con el mínimo permiso. Los tokens de npm, de GitHub y de los servidores de prueba solo pueden hacer lo que necesitan, y duran lo menos posible.
- Un plan para cuando pase. Si un paquete comprometido llega a una computadora o a un servidor de pruebas, hay que asumir que todas las claves de ese entorno están expuestas y cambiarlas. Tener esa lista preparada de antemano ahorra horas cuando cada minuto cuenta.
- Pruebas desde afuera. Un pentesting muestra qué puede hacer un atacante con lo que encuentra, y una auditoría de ciberseguridad revisa versiones, dependencias y accesos de forma ordenada.
En resumen
2026 dejó claro que la seguridad de una aplicación Node.js no depende solo del código que escribe tu equipo. Depende de cientos de piezas ajenas, de la versión de Node.js en la que corre y de quién tiene las llaves para publicar y desplegar.
Ninguna de estas medidas es difícil por separado. Lo difícil es sostenerlas en el tiempo, proyecto tras proyecto. Si quieres saber en qué estado está el tuyo, nuestros expertos en ciberseguridad pueden ayudarte a revisarlo.
Preguntas frecuentes
¿Qué es un ataque a la cadena de suministro de software?
Es un ataque que no apunta directo a tu sistema, sino a algo de lo que tu sistema depende: una librería, una herramienta o el proceso que publica el código. Si el atacante logra meter código malicioso en un paquete que tú instalas, ese código entra a tu proyecto con tu propio permiso.
¿Qué paquetes de npm fueron atacados en 2026?
Entre los casos más conocidos están node-ipc en mayo, una campaña de 45 paquetes falsos que imitaban nombres internos de empresas (reportada por Microsoft) y, en agosto, un gusano que empezó en keyv y llegó a más de 440 paquetes. En todos los casos el objetivo era robar contraseñas, tokens y claves de acceso.
¿Qué versiones de Node.js tienen soporte en noviembre de 2026?
Node.js 22, 24 y 26. Node.js 20 dejó de recibir parches el 30 de abril de 2026 y Node.js 25 el 1 de junio de 2026. Node.js 22 tiene soporte hasta el 30 de abril de 2027, así que conviene planificar ya el paso a la 24 o la 26.
¿Cómo protejo mi proyecto Node.js de un ataque a la cadena de suministro?
Con varias capas: fijar las versiones exactas de las dependencias, no instalar actualizaciones el mismo día que salen, desactivar los scripts de instalación cuando no hacen falta, dar permisos mínimos a los tokens de publicación y de CI, y tener un plan para cambiar todas las claves si un paquete comprometido llega a tu entorno.