Mini Shai-Hulud: el gusano npm devora la cadena de suministro

7 min de lectura

El 11 de mayo de 2026, Microsoft Security Research informa de una nueva ola del gusano npm Shai-Hulud: 170 paquetes npm afectados y dos paquetes PyPI, distribuidos en 404 versiones maliciosas de paquetes. Es la primera campaña coordinada que afecta simultáneamente a npm y PyPI. Lo notable no es la cifra, sino su arquitectura. Mini Shai-Hulud roba credenciales y, además, se propaga por sí mismo a través de los propios canales de publicación fiables que sostienen las cadenas de suministro de software modernas.

Lo más importante en resumen

El gusano se propaga por sí mismo: Los permisos de OIDC y publicación robados generan nuevas versiones maliciosas bajo identidades reales de mantenedores, sin necesidad de nuevos accesos por phishing.
Persistencia más allá del paquete: El código malicioso se aloja en parte en las configuraciones de los desarrolladores y permanece activo incluso después de eliminar el paquete infectado.
Los tokens son la puerta de entrada: Quien apueste por npm Trusted Publishing y WebAuthn en lugar de tokens de larga duración, cerrará la principal vía de propagación.

Relacionado:La brecha de Splunk sin inicio de sesión / Identidades de máquinas en el offboarding

Una segunda ola, mayor y más coordinada

Shai-Hulud no es un nombre nuevo. Entre el 24 de noviembre y el 1 de diciembre de 2025, la primera ola comprometió cientos de paquetes npm, entre los que se incluían componentes de los ecosistemas de Zapier, PostHog, Postman, ENS Domains y AsyncAPI. La variante que Microsoft documenta a principios de mayo de 2026 lleva el nombre de Mini Shai-Hulud y da un paso más. Vuelve a afectar a proyectos destacados como TanStack, Mistral AI, UiPath, OpenSearch y AntV, y abarca por primera vez ambos grandes registros.

Las 404 versiones maliciosas representan la cantidad de estados de paquetes manipulados, distribuidos entre los 170 paquetes npm y los dos paquetes PyPI. Esta cifra no tiene nada que ver con errores HTTP. Para los equipos de seguridad, esto cambia el enfoque de la búsqueda: ya no se trata de un único paquete comprometido, sino de una cadena de publicaciones que se retroalimentan.

La mecánica: preinstall se ejecuta antes de cada prueba

El ataque comienza en la debilidad más vulnerable del proceso de instalación. Un script malicioso preinstall en la package.json se ejecuta automáticamente al instalar, antes de que las pruebas o revisiones de seguridad puedan actuar. Este ventanillo temporal es el punto de entrada. En él, un script de configuración llamado set_bun.js instala, si es necesario, la alternativa Runtime JavaScript Bun y ejecuta a través de ella el propio código dañino contenido en el archivo bun_environment.js.

Lo que sucede después es una cosecha sistemática. El código malicioso descarga un runner de GitHub Actions y utiliza el escáner de credenciales TruffleHog para extraer secretos de los repositorios y variables de entorno. La presa va directamente a repositorios bajo control de los atacantes. Se roban mucho más de solo tokens de npm: accesos AWS-SSO e IMDS-v2, datos de inicio de sesión de Azure, Google Cloud y Kubernetes, claves SSH, secretos de configuración locales e incluso billeteras criptográficas.

404 versiones

paquetes maliciosos distribuyeron Mini Shai-Hulud a través de 170 paquetes de npm y dos de PyPI, identificados por Microsoft Security Research el 11 de mayo de 2026.

Fuente: Microsoft Security Blog

¿Por qué el gusano sobrevive aunque el paquete ya no esté

La verdadera diferencia con respecto a los ataques tradicionales de cadena de suministro radica en su propagación. Mini Shai-Hulud aprovecha los derechos OIDC y de publicación robados para lanzar nuevas versiones maliciosas bajo las identidades de mantenedores reales. A través de GitHub Trusted Publishing y scripts de ciclo de vida de npm, el ataque se propaga así por los canales de publicación confiables, sin que los atacantes tengan que volver a hacer phishing.

Aún más incómodo es su persistencia. Según Microsoft, el código malicioso se ancla parcialmente mediante hooks de inicio de sesión en el archivo .claude/settings.json y a través de la interfaz GraphQL de GitHub. Así, el ataque sigue viviendo en el entorno de desarrollo, no solo en la dependencia. Quien elimina el paquete infectado y cree que ha terminado, pasa por alto el mecanismo que vuelve a activarse cada vez que se inicia nuevamente la herramienta.

La nueva superficie de ataque: herramientas de desarrollo de IA y runtimes alternativos

Exactamente aquí está la lección que trasciende este único incidente. El gusano no solo se vale de scripts clásicos de npm, sino también de una runtime alternativa con Bun y archivos de hook de herramientas modernas de codificación de IA, junto con un mecanismo de persistencia que rara vez tienen en cuenta los auditorías convencionales. Una SBOM enumera dependencias, pero no enumera configuraciones de hook en el entorno de desarrollo.

Para la respuesta ante incidentes, esto significa ampliar el alcance. Quien investigue una compromisión en la cadena de suministro deberá revisar en el futuro también los archivos de configuración de asistentes de IA, archivos de hook locales y runtimes distintos a Node. No se trata de pánico ante la IA. Es simplemente la observación fría de que la superficie de ataque de CI/CD ha crecido con herramientas que hace dos años no estaban presentes en todos los equipos de desarrollo.

Defensa: Tokens sustituir, identidad reforzar, pipeline firmar

La buena noticia es que las medidas más efectivas son principios, no productos. Microsoft y varias empresas de seguridad como Akamai, Snyk y StepSecurity, que informaron en paralelo a la campaña, llegan a un núcleo consistente. Los mantenedores deberían utilizar npm Trusted Publishing en lugar de tokens de larga vida, ya que un token robado es el combustible de la auto-propagación. Una autenticación de dos factores basada en WebAuthn protege mejor que TOTP, que puede ser phishing. Y las firmas de comités hacen visibles las versiones falsas.

En el ámbito del usuario, importa la velocidad. Quien pueda estar afectado debe rotar inmediatamente los datos de acceso expuestos, en lugar de esperar. La creación automática de SBOM y el escaneo sin agentes ayudan a detectar las versiones manipuladas incluso antes de su aparición. Reglas para reducir superficies de ataque pueden bloquear scripts obfuscatos antes de que se ejecuten. Para las empresas alemanas entra también una dimensión legal. NIS2 convierte la obligación de cuidado en la cadena de suministro en una exigencia verificable. Un incidente como este es así tanto un tema técnico como un tema de documentación.

Preguntas frecuentes

¿Qué es Mini Shai-Hulud?

Mini Shai-Hulud es una variante del gusano npm Shai-Hulud de 2025. La ola documentada por Microsoft el 11 de mayo de 2026 comprometió 170 paquetes npm y dos paquetes PyPI sobre 404 versiones maliciosas y se propaga de forma autónoma a través de los canales de publicación de la cadena de suministro de software.

¿Cómo infecta el gusano un sistema?

A través de un script malicioso preinstall, que se ejecuta automáticamente y antes de todos los tests al instalar un paquete. Instala la runtime de Bun, carga un payload y escanea con TruffleHog buscando credenciales, que luego fluyen hacia los atacantes.

¿Por qué no basta con eliminar el paquete infectado?

Porque el código malicioso se ancla en parte fuera de la dependencia, por ejemplo, mediante hooks de SessionStart en la configuración de herramientas de codificación de inteligencia artificial y a través de la interfaz GitHub-GraphQL. Esta persistencia vuelve a activarse cada vez que se inicia la herramienta, incluso si el paquete ya fue eliminado.

¿Qué datos de acceso están afectados?

Se roban tokens de npm, accesos AWS-SSO e IMDS-v2, credenciales de Azure, Google Cloud y Kubernetes, claves SSH, configuraciones locales de secretos y wallets criptográficas. Quien sospeche de una compromisión debe rotar inmediatamente los datos de acceso expuestos.

¿Qué significa este incidente para las obligaciones de NIS2?

NIS2 exige una obligación de cuidado verificable en la cadena de suministro. Un incidente de cadena de suministro de este tipo afecta así más allá de la defensa técnica las obligaciones de documentación y reporte de las empresas afectadas.