TL;DR
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, mapas, visualización 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.
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ó 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 no era ejecutar malware una sola vez. El objetivo era recopilar credenciales que permitieran al malware publicar otra 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 web 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 paquetes que la víctima puede mantener, modificar tarballs, 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 donde 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 tokens npm estáticos y de larga duración. Aun así, el atacante obtuvo una ruta de publicación válida mediante mecánicas de repositorio y workflow. El resultado fueron versiones maliciosas en el namespace de TanStack con procedencia aparentemente válida.
El hilo común no es una herramienta rota. Es la cantidad de autoridad concentrada en entornos de desarrollo y workflows de release.
npm es 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 descargarla 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 gran distribución a versiones maliciosas |
| Scripts de ciclo de vida | Soportan setup de paquetes y builds nativos | Ejecutan código 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 el workflow o el límite de confianza se compromete |
La lección no es abandonar npm. La lección es reducir la confianza automática en cada etapa donde se ejecuta código.
Qué deben hacer los equipos ahora
Empieza por el entorno de build y desarrollo. Cualquier máquina o runner de CI que instaló un paquete afectado debe tratarse como expuesto hasta revisar las credenciales.
- Revisar lockfiles y logs del gestor de paquetes para detectar versiones afectadas instaladas el 2026-05-19 o después
- Rotar credenciales npm, GitHub, cloud, Vault, SSH, Docker y bases de datos accesibles desde esos sistemas
- Auditar paquetes de mantenedores para detectar versiones inesperadas, hooks de instalación o dependencias git añadidas
- Usar instalaciones estrictas con lockfile como
npm ci,pnpm install --frozen-lockfileoyarn install --frozen-lockfile - Desactivar scripts de ciclo de vida donde sea práctico con
--ignore-scripts, especialmente en jobs de CI que no necesitan builds nativos - Añadir periodos de enfriamiento o revisiones para que versiones recién publicadas no entren automáticamente en producción
- Monitorizar tráfico saliente desde CI y estaciones de desarrolladores hacia 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 se ejecuta en el navegador. Muchos sitios de producción cargan scripts de terceros, SDKs, payloads de tag managers, 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 build y aun así entregar comportamiento riesgoso al navegador más tarde.
cside monitoriza el comportamiento de scripts cuando 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 cuando el código ya está en producción.
La defensa correcta es por capas: proteger la ruta del registro, endurecer CI, rotar secretos rápido y monitorizar el comportamiento en runtime donde los usuarios ejecutan el código.
