El gusano auto‑propagante Shai-Hulud 2.0 ha reaparecido en el ecosistema npm, convirtiéndose en cuestión de días en una de las campañas de ataque a la cadena de suministro de software más amplias de los últimos años. Según estimaciones de Wiz, en menos de tres días se habrían visto comprometidos decenas de miles de desarrolladores y sus infraestructuras de CI/CD, con fugas masivas de secretos y credenciales.
Alcance del ataque Shai-Hulud 2.0 en la cadena de suministro npm
Los investigadores han identificado cientos de versiones infectadas de paquetes npm populares, incluidos proyectos relacionados con servicios como Zapier, ENS Domains, PostHog, Postman y AsyncAPI, entre otros. Estos paquetes troyanizados se utilizaron como canal para el robo de secretos de desarrolladores, tokens de GitHub y npm, así como credenciales de proveedores cloud.
De acuerdo con Wiz, a fecha de 24 de noviembre de 2025 más de 25 000 repositorios de GitHub ya contenían secretos filtrados, y se creaban alrededor de 1000 nuevos repositorios comprometidos cada 30 minutos. BleepingComputer reportó aproximadamente 27 600 resultados de búsqueda relacionados con la campaña, mientras que se detectaron en torno a 350 cuentas únicas de npm implicadas en la distribución del malware.
La aparición de miles de repositorios nuevos con información sensible expone un patrón claro: muchos mantenedores habían instalado sin saberlo paquetes npm modificados maliciosamente y los ejecutaron en entornos de desarrollo o pipelines de CI/CD. Con ello, el gusano obtuvo acceso a tokens activos y a repositorios privados, explotando la confianza inherente a la cadena de suministro de software.
Evolución del gusano Shai-Hulud: de la primera campaña a la versión 2.0
La primera aparición de Shai-Hulud se remonta a mediados de septiembre de 2025, cuando se detectaron 187 paquetes npm modificados. En aquella campaña, el malware aprovechaba la herramienta legítima TruffleHog, un escáner de secretos ampliamente utilizado, para localizar y exfiltrar credenciales en repositorios privados.
La versión inicial del gusano clonaba públicamente cualquier repositorio privado asociado a la cuenta comprometida, añadiendo el prefijo “migration” al nombre. De este modo, los atacantes obtenían acceso a claves incrustadas en código, tokens y al propio código fuente, abriendo la puerta tanto a compromisos directos como a ataques encadenados sobre terceros.
Además, Shai-Hulud incorporaba desde el inicio un mecanismo de auto‑propagación: descargaba todos los paquetes del mantenedor, modificaba el package.json para inyectar un script malicioso (bundle.js), y después los volvía a empaquetar y publicar en npm. Este enfoque provocaba una “troyanización automática” en cascada de dependencias aguas abajo, acelerando la propagación a proyectos que confiaban en dichos paquetes.
Análisis técnico de Shai-Hulud 2.0 y su comportamiento destructivo
En Shai-Hulud 2.0, el código malicioso se ejecuta durante la fase pre-install, es decir, antes de completar la instalación del paquete. Esto incrementa significativamente el riesgo para entornos de desarrollo y CI/CD, ya que la infección puede producirse incluso si la instalación de la dependencia falla o se cancela.
Según el análisis de Step Security, el malware se compone principalmente de dos archivos: setup_bun.js, un dropper disfrazado de instalador de la plataforma Bun, y un fichero de aproximadamente 10 MB llamado bun_environment.js. Este último presenta una fuerte ofuscación: cadenas codificadas en hexadecimal con miles de elementos, bucles anti‑análisis y funciones enrevesadas para extraer dinámicamente las cadenas durante la ejecución.
Fases de la intrusión y robo de secretos
La versión actual del gusano implementa cinco etapas de ataque, centradas en identificar y extraer de forma sistemática:
- Tokens de GitHub y npm utilizados por desarrolladores y bots.
- Credenciales de AWS, Google Cloud Platform y Microsoft Azure.
- Secretos de CI/CD, como variables de entorno y claves de despliegue.
Un aspecto especialmente preocupante de Shai-Hulud 2.0 es su comportamiento destructivo. Si durante la ejecución no se cumplen simultáneamente cuatro condiciones —autenticación exitosa en GitHub, capacidad para crear un repositorio, detección de un token de GitHub y de un token de npm— el malware puede pasar a sobrescribir por completo el directorio home del usuario. Con ello, la campaña deja de ser únicamente un ataque de espionaje para convertirse en un incidente potencialmente devastador para la productividad y la disponibilidad.
Los secretos robados se publican en repositorios creados automáticamente en GitHub con la descripción “Sha1-Hulud: The Second Coming”. Este patrón facilita la identificación de rastros de la campaña, pero también permite a los atacantes centralizar y procesar de forma masiva los datos exfiltrados.
Impacto en la seguridad de la cadena de suministro y medidas de mitigación
Firmas como Aikido Security han identificado en torno a 500 paquetes comprometidos, mientras que Koi Security eleva la cifra a más de 800 paquetes maliciosos si se consideran todas sus versiones. Estos números ilustran el efecto dominó típico de los ataques a la cadena de suministro: comprometer unos pocos paquetes clave basta para impactar a miles de proyectos y organizaciones.
Entre las recomendaciones prioritarias para equipos de desarrollo y DevSecOps destacan:
- Limpiar la caché de npm y volver a versiones de paquetes anteriores al 21 de noviembre de 2025 en caso de duda sobre su integridad.
- Rotar y revocar todos los secretos y tokens de CI/CD (GitHub, npm, credenciales cloud), incluidos los utilizados por pipelines automatizados y bots.
- Auditar los repositorios en busca de repos sospechosos o commits inusuales, especialmente con referencias a
huludo descripciones extrañas. - Cuando sea posible, deshabilitar scripts preinstall y postinstall en CI o aplicar políticas estrictas de paquetes de confianza y bloqueo de versiones.
En respuesta a esta y otras campañas como S1ngularity, GitHub ha anunciado medidas adicionales: doble factor de autenticación obligatorio para publicaciones locales, reducción del tiempo de vida de los tokens PAT a siete días, transición de TOTP hacia autenticación FIDO y otras mejoras. Sin embargo, al tratarse de cambios progresivos, la responsabilidad inmediata de protección sigue recayendo en las propias organizaciones.
El caso de Shai-Hulud 2.0 subraya que la seguridad de la cadena de suministro de software ya no es opcional: un único paquete npm comprometido puede desencadenar una filtración masiva de secretos y daños operativos severos. Adoptar el principio de mínimos privilegios, rotar tokens de forma regular, evitar almacenar secretos en código y controlar rigurosamente las dependencias son pasos imprescindibles. Es un momento adecuado para que los equipos revisen sus políticas de seguridad, fortalezcan sus controles en CI/CD y evolucionen hacia un modelo de confianza mucho más estricto frente a paquetes externos.
