TL;DR: el gusano npm Mini Shai-Hulud
Mini Shai-Hulud es una advertencia sobre cómo se propaga un compromiso de npm después de la primera publicación maliciosa. El atacante no necesita comprometer cada aplicación aguas abajo directamente. Necesita una cuenta de mantenedor, una ruta de CI o un punto de ejecución durante la instalación que exponga credenciales.
Al 2026-05-19, Socket reportó 639 versiones de paquetes comprometidas en 323 paquetes únicos en una ola de Mini Shai-Hulud concentrada alrededor del ecosistema @antv. El conjunto afectado incluía paquetes de gráficos, grafos, mapas y wrappers de React usados por equipos de ingeniería que quizá nunca consideran esas dependencias como críticas para la seguridad.
El patrón es el problema real. npm es útil porque centraliza publicación, escaneo y retirada. Esa misma centralización se vuelve peligrosa cuando scripts de ciclo de vida, publicación confiable y credenciales de mantenedores se abusan para convertir paquetes en una red de distribución.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Qué ocurrió en la ola de AntV
La ola de AntV usó un punto de entrada habitual en npm: ejecución durante la instalación. El análisis de Socket describe un payload index.js en la raíz que modificaba package.json para ejecutarse durante preinstall.
Eso importa porque npm install, pnpm install y yarn install no son pasos pasivos de descarga. Los scripts de ciclo de vida de paquetes pueden ejecutar código antes de que un desarrollador revise el contenido del paquete o ejecute la aplicación.
El payload estaba muy ofuscado. Socket reportó que usaba decodificación de strings en tiempo de ejecución, exfiltración cifrada, uso de la API de GitHub, uso de la API del registro npm y una ruta HTTPS fija de exfiltración. El objetivo era recopilar credenciales que permitieran al malware volver a publicar, no solo ejecutarse una vez.
Cómo Mini Shai-Hulud crea el efecto bola de nieve
El payload apunta a entornos de desarrolladores y CI/CD porque esos entornos tienen poder de publicación. Una aplicación de navegador puede necesitar solo un paquete de gráficos, pero la máquina o el workflow que lo instala también puede tener acceso a npm, GitHub, AWS, Kubernetes, Vault, SSH, Docker o credenciales de bases de datos.
Los objetivos de credenciales incluyen:
- Tokens de GitHub y material OIDC de GitHub Actions
- Tokens de publicación npm
- Credenciales de AWS y metadatos de instancia
- Archivos de cuentas de servicio de Kubernetes
- Tokens de HashiCorp Vault
- Archivos de autenticación de Docker
- Claves SSH y claves privadas
- Cadenas de conexión a bases de datos
Cuando el malware encuentra credenciales npm utilizables, puede enumerar los paquetes que la víctima puede mantener, modificar tarballs de paquetes, añadir un hook de instalación, incrementar versiones y volver a publicar paquetes comprometidos bajo una identidad de mantenedor confiable.
Por qué importan Axios y TanStack
La ola de AntV no ocurrió de forma aislada. El ecosistema npm ha visto una serie de incidentes en los que atacantes abusan de mantenedores confiables, dependencias transitivas y automatización de CI/CD.
El análisis de Axios de Datadog describe cómo un atacante secuestró una cuenta de mantenedor de Axios el 2026-03-31 y publicó versiones maliciosas de axios que añadían la dependencia troyanizada plain-crypto-js. Esa dependencia descargaba y ejecutaba un troyano de acceso remoto multiplataforma durante la instalación.
El análisis de TanStack de Endor Labs muestra otra lección. TanStack usaba publicación confiable OIDC de npm, que elimina los tokens npm estáticos y de larga duración. Aun así, el atacante obtuvo una ruta de publicación válida mediante las mecánicas del repositorio y del workflow. El resultado fueron versiones maliciosas en todo el namespace de TanStack con una procedencia de apariencia válida.
Ninguna herramienta rota por sí sola explica el patrón. El hilo común es la cantidad de autoridad concentrada en los entornos de desarrollo y los workflows de release.
npm es a la vez una herramienta defensiva y una ruta de ataque
npm ofrece a los defensores un lugar central para inspeccionar paquetes, marcar malware, deprecar releases y revocar tokens. Ese modelo centralizado es mejor que descargas opacas y aisladas.
Pero npm también ofrece a los atacantes una capa central de distribución. Si un paquete confiable publica una versión maliciosa, los usuarios aguas abajo pueden obtenerla mediante instalaciones normales, actualizaciones de lockfile, rebuilds de CI o resolución de dependencias transitivas.
| Función de npm | Valor defensivo | Valor para el atacante |
|---|---|---|
| Registro central | Permite escaneo, avisos y retirada | Da amplia distribución a las versiones maliciosas |
| Scripts de ciclo de vida | Soportan la configuración de paquetes y builds nativos | Ejecutan código del atacante durante la instalación |
| Cuentas de mantenedor | Permiten publicar rápido | Convierten una identidad comprometida en muchos paquetes envenenados |
| Publicación confiable | Reduce la exposición de tokens de larga duración | Puede abusarse si se compromete el workflow o el límite de confianza |
La lección es reducir la confianza automática en cada etapa donde se ejecuta código, no abandonar npm.
Qué deben hacer los equipos ahora
Empieza por el entorno de build y desarrollo. Cualquier máquina o runner de CI que haya instalado un paquete afectado debe tratarse como expuesto hasta revisar las credenciales.
- Revisa los lockfiles y los logs del gestor de paquetes para detectar versiones afectadas instaladas el 2026-05-19 o después
- Rota las credenciales de npm, GitHub, cloud, Vault, SSH, Docker y bases de datos accesibles desde esos sistemas
- Audita los paquetes propiedad de los mantenedores para detectar versiones inesperadas, hooks de instalación o dependencias git añadidas
- Usa instalaciones estrictas con lockfile como
npm ci,pnpm install --frozen-lockfileoyarn install --frozen-lockfile - Desactiva los scripts de ciclo de vida donde sea práctico con
--ignore-scripts, especialmente en jobs de CI que no necesitan builds nativos - Añade periodos de espera para dependencias o puertas de revisión para que las versiones de paquetes recién publicadas no entren automáticamente en producción
- Monitoriza el tráfico saliente desde CI y las estaciones de los desarrolladores en busca de rutas sospechosas de exfiltración
Estos controles reducen la probabilidad de que un paquete malicioso se convierta en un incidente de publicación en todos los paquetes que mantiene un desarrollador.
Dónde encaja cside
cside no es un escáner del registro npm y no reemplaza el endurecimiento de CI/CD. Sigues necesitando escaneo de dependencias, lockfiles, higiene de tokens y controles estrictos de release.
cside cubre la parte de la cadena de suministro que ocurre en el runtime del navegador. Muchos sitios en producción cargan scripts de terceros, SDKs, payloads de tag managers, paquetes de analítica y código entregado dinámicamente que nunca se comporta como una dependencia npm fija. Un paquete o proveedor puede parecer legítimo en el momento del build y aun así entregar comportamiento riesgoso al navegador más tarde.
cside monitoriza el comportamiento de los scripts mientras se ejecutan en el navegador del usuario. Eso incluye cambios de scripts, acceso inesperado a datos, intentos sospechosos de exfiltración y actividad del lado del navegador que los escáneres de dependencias no pueden ver una vez que el código ya está en producción.
La defensa correcta es por capas: protege la ruta del registro, endurece la CI, rota los secretos rápido y monitoriza el comportamiento en runtime donde los usuarios realmente ejecutan el código.
