Los paquetes npm maliciosos ya no son un incidente aislado: en 2025 aparecieron 454.600 nuevos, y el total bloqueado desde que existe el registro supera ya el millón doscientos mil. Si tu web, tu tienda online o el panel interno de tu empresa se construyó con JavaScript o Node.js, y la inmensa mayoría se construye así, depende de una cadena de decenas o cientos de paquetes que nadie en tu equipo ha revisado uno por uno. Esto es lo que ha cambiado y lo que conviene comprobar antes de que ese código llegue a producción.
Un paquete npm malicioso es una librería publicada en el registro de Node.js que oculta código para robar credenciales, tokens o datos del servidor donde se instala. En 2025 se identificaron 454.600 nuevos, casi todos en npm, y el mayor brote, el gusano Shai-Hulud, comprometió más de 500 paquetes en cuestión de días.
La magnitud de los paquetes npm maliciosos en 2025
En 2025, Sonatype identificó 454.600 paquetes npm maliciosos nuevos, un 75% más que el año anterior, según su informe anual sobre la cadena de suministro de software. La cifra acumulada de paquetes bloqueados en npm, PyPI, Maven Central, NuGet y Hugging Face desde que existen estos registros supera ya el millón doscientos treinta mil. Más del 99% de ese malware de código abierto apareció en npm, el gestor de paquetes de Node.js que usa prácticamente cualquier proyecto moderno en JavaScript o TypeScript, desde una tienda online hasta el panel interno de una fábrica. Si tu proyecto sigue en Node.js 20, revisar dependencias importa todavía más: una versión sin parches de seguridad no corrige lo que puedan aprovechar estos paquetes.
El motivo es sencillo: una aplicación media depende de unos 180 paquetes de terceros, y cada uno puede a su vez depender de otros. Basta con que uno solo quede comprometido para que el código malicioso llegue al servidor sin que nadie lo haya escrito ni revisado. El informe distingue varios tipos de ataque: el 55,9% es abuso del propio registro para publicar rápido y llegar a más instalaciones, y un 3,9% se dedica a robar credenciales y tokens de acceso.
Un ataque a la cadena de suministro de software no compromete la aplicación final: compromete una pieza que esa aplicación importa sin cuestionarla, como una librería o una herramienta de compilación, y usa la confianza que existe en esa pieza para llegar a todas las que la instalan.
Shai-Hulud, el gusano que propagó paquetes maliciosos
El caso que mejor explica el riesgo ocurrió el 14 de septiembre de 2025, cuando un gusano bautizado como Shai-Hulud empezó a propagarse solo entre paquetes del ecosistema npm, sin que ninguna empresa afectada hubiera cambiado una sola línea de su propio código.
Cómo entra el código malicioso en tu proyecto
Shai-Hulud no atacó a las empresas directamente: atacó a los mantenedores de las librerías que esas empresas ya tenían instaladas. El gusano robaba los tokens de publicación de un desarrollador y los usaba para inyectar un script malicioso en sus propios paquetes, que volvía a publicar como una versión nueva. Cualquier proyecto que actualizara esa dependencia ejecutaba ese script automáticamente al instalar, normalmente a través de un hook postinstall que corre sin pedir permiso. Así se comprometieron más de 500 paquetes en cuestión de días.
La respuesta de GitHub y npm tras el ataque
GitHub, que gestiona el registro de npm, retiró los paquetes afectados y publicó un plan para reforzar la seguridad de toda la cadena de publicación. Desde octubre de 2025 los tokens de escritura caducan a los siete días en lugar de treinta, los tokens clásicos sin caducidad se están retirando y la autenticación en dos pasos pasó a ser obligatoria para publicar. La alternativa que promueve GitHub es la publicación de confianza: en vez de un token guardado en el servidor de integración continua, cada publicación se autentica con una credencial temporal que expira al terminar el proceso.
Qué revisar en las dependencias npm antes de publicar
Auditar cada paquete uno por uno no es viable: ninguna empresa tiene tiempo para leer el código de 180 dependencias, y menos el de las decenas de miles que dependen de ellas. Lo que sí es razonable es exigir un puñado de prácticas concretas antes de que una actualización llegue a producción.
- Usar npm ci en lugar de npm install en los despliegues, para instalar exactamente las versiones fijadas en el lockfile y no lo último que haya publicado cada paquete.
- Ejecutar npm audit o una herramienta equivalente de análisis de dependencias en cada integración, no solo al arrancar el proyecto.
- Revisar antes de fusionar cualquier cambio que toque el package-lock.json, igual que se revisa cualquier otro cambio de código.
- Exigir autenticación en dos pasos a quien publique paquetes propios de la empresa, y migrar a publicación de confianza en cuanto la plataforma de integración continua lo soporte.
Ninguna de estas medidas exige contratar personal nuevo: es una cuestión de proceso, no de presupuesto. La diferencia la marca que alguien en el equipo tenga la responsabilidad explícita de aplicarlas, igual que hay alguien responsable del backup o del certificado SSL. Conviene revisar estas dependencias junto a los riesgos habituales de las APIs que exponen, porque un paquete comprometido casi siempre busca las mismas credenciales que un endpoint mal protegido.
Qué implica esto en sectores muy distintos
El riesgo no distingue de sector, aunque se nota distinto según qué construye cada empresa. Una tienda online que cobra con pasarela propia corre el mismo riesgo de que su checkout quede comprometido por una dependencia infectada que una empresa de logística cuyo panel de seguimiento de flotas se construyó con React. En el sector industrial, donde cada vez hay más cuadros de mando a medida conectados a máquinas o sensores, un paquete comprometido puede llegar a exponer credenciales de sistemas que no deberían tocar internet. En servicios profesionales, despachos, consultoras, clínicas, el riesgo suele estar en el formulario de contacto o el área privada de clientes, construidos muchas veces con el mismo stack de JavaScript que cualquier otra web moderna, y con las mismas dependencias de terceros.
Para un equipo de desarrollo en Barcelona que mantiene varios de estos proyectos a la vez, la pregunta no es si alguna dependencia se va a ver afectada alguna vez, sino cuánto tiempo tardará en detectarlo cuando ocurra. Contar con una auditoría periódica del código en producción o con soporte técnico que revise dependencias de forma recurrente reduce esa ventana de exposición de meses a días.
Preguntas frecuentes sobre paquetes npm maliciosos
¿Cómo sé si mi web usa un paquete npm comprometido?
Revisando el resultado de npm audit o de una herramienta de análisis de dependencias contra las bases de datos públicas de vulnerabilidades. Si tu web la gestiona un tercero, pídele ese informe: ningún proveedor serio debería negarse a mostrarlo.
¿Basta con actualizar todas las dependencias a la última versión?
No siempre: una actualización automática puede instalar precisamente la versión recién infectada, sobre todo si se publicó hace pocas horas y todavía no hay alerta pública. Conviene fijar versiones con el lockfile, revisar el registro de cambios antes de actualizar y no ejecutar la actualización en caliente sin pasar antes por pruebas.
¿Esto afecta solo a proyectos grandes con muchos desarrolladores?
No. Afecta a cualquier proyecto en JavaScript o Node.js, tenga uno o veinte desarrolladores, porque el riesgo está en las dependencias que instala, no en el tamaño del equipo que las mantiene. Una web pequeña con pocos paquetes puede estar tan expuesta como una plataforma grande con un departamento de desarrollo propio.