El ecosistema de JavaScript/npm se enfrenta a un nuevo hito en las amenazas a la cadena de suministro con el resurgimiento de Shai-Hulud 2.0 el 24 de noviembre de 2025. Este gusano autopropagable ataca específicamente a los mantenedores de software de código abierto y a los paquetes que publican. Esta nueva variante supone un cambio de paquetes maliciosos aislados a un mecanismo de infección coordinado y automatizado.
El impacto ya es grave. Cientos de paquetes de npm y decenas de miles de repositorios de GitHub se han visto afectados, lo que ha generado un «radio de acción» sin precedentes para un ataque a la cadena de suministro de JavaScript. Para los lectores familiarizados con el análisisOPSWATsobre Shai-Hulud 1.0, la versión 2.0 amplía drásticamente las capacidades y la escala operativa del gusano: ejecución más temprana, propagación más amplia y mayor resistencia a las medidas de corrección estándar, lo que lo eleva de una amenaza preocupante a un incidente a nivel de todo el ecosistema.
Datos básicos sobre Shai-Hulud 2.0
- Gusano autopropagable: Shai-Hulud 2.0 roba credenciales de GitHub, se reempaqueta y se vuelve a publicar en todo el catálogo de npm de un mantenedor.
- Propagación masiva:más de 700 paquetes npm infectados, más de 25 000 repositorios de GitHub, 500 mantenedores afectados; se añaden más de 1000 repositorios nuevos cada 30 minutos (Wiz).
- Repercusión en otros ecosistemas: también se ha observado en Maven/Java a través de la sincronización automática de npm a Maven.
- Riesgos principales: exposición de CI/CD, secretos comprometidos, ejecución durante la instalación y registros contaminados.
- Defensa: precisión de la SBOM, verificación de la procedencia, supervisión en tiempo de ejecución y estrictas medidas de seguridad en el manejo de tokens y secretos.
Alcance y agravamiento: ¿qué alcance tiene el daño?
La magnitud y la rapidez de la propagación de Shai-Hulud 2.0 han superado todo lo visto en incidentes recientes relacionados con la cadena de suministro. Lo que comenzó como un ataque selectivo contra npm se convirtió rápidamente en una infección sistémica y multiplataforma que ha afectado a miles de proyectos y a cientos de mantenedores.
A diferencia del malware típico de npm, que suele consistir en un único paquete troyanizado, Shai-Hulud 2.0 se comporta como un gusano. Tras infectar el sistema de un desarrollador, roba las credenciales de GitHub, se reempaqueta y se vuelve a publicar en todo el conjunto de paquetes del mantenedor, convirtiendo a cada víctima en un nuevo punto de distribución. El resultado es una propagación rápida y exponencial por todo el ecosistema.
Paquetes comprometidos
Cientos de paquetes de npm se han visto comprometidos. Entre ellos se encuentran proyectos de gran repercusión gestionados por organizaciones consolidadas, lo que aumenta el riesgo para los usuarios finales.
Propagación rápida y exponencial
Se ha observado que el gusano genera más de 1 000 nuevos repositorios maliciosos en GitHub cada 30 minutos (Wiz), gracias a la publicación automatizada a partir de credenciales robadas. Cada nueva víctima se convierte en un nodo de propagación, lo que multiplica el impacto total en cada ciclo.
Secretos al descubierto
El componente de robo de credenciales de Shai-Hulud 2.0 está resultando especialmente perjudicial. Entre los datos confidenciales filtrados que se han verificado se incluyen más de 1 500 credenciales y tokens de las principales plataformas: GitHub, AWS, Google Cloud y Azure.
Este volumen de credenciales confidenciales supone una filtración generalizada en múltiples entornos de nube, con posibilidades de que se produzca una explotación prolongada.
Iniciativas de rehabilitación
Afortunadamente, varios mantenedores de renombre, como Zapier, PostHog y Postman, ya han recuperado el control de sus paquetes. Las versiones maliciosas se han eliminado de npm, y muchos repositorios afectados están siendo recuperados o limpiados.
Sin embargo, el incidente sigue en curso. A pesar de las rápidas medidas correctivas, las organizaciones deben seguir supervisando el estado de las dependencias, los flujos de trabajo de CI y las cuentas de GitHub para detectar cualquier indicio de nuevas fugas de credenciales o de republicaciones automáticas.
Repercusión entre ecosistemas: npm → Maven/Java
Cabe destacar que esta tendencia también ha afectado a otros ecosistemas, como Maven/Java, a través de la conversión automatizada de artefactos de npm a Maven (JFrog).
-
Aunque npm sigue siendo el objetivo principal de Shai-Hulud 2.0, esta oleada ha puesto de manifiesto el riesgo de propagación entre ecosistemas, concretamente a proyectos Java/Maven. Los investigadores de seguridad identificaron el artefacto malicioso de Maven:
org.mvnpm:posthog-node:4.18.1que contiene la misma carga útil (setup_bun.jsybun_environment.js) detectados en paquetes de npm comprometidos (The Hacker News) .
- Mecanismo: Las herramientas de conversión automatizadas reconstruyen los paquetes de npm como artefactos de Maven para proyectos Java. Los equipos que no utilicen directamente Node.js pueden verse afectados si sus proyectos dependen de estos artefactos duplicados.
Esto pone de manifiesto el riesgo de los ataques a la cadena de suministro, independientemente del ecosistema. Incluso los proyectos que no utilizan directamente npm pueden verse expuestos a este riesgo a través de las herramientas automatizadas.
Shai-Hulud 2.0 demuestra que los gusanos modernos de la cadena de suministro son amenazas multifásicas que tienen en cuenta el entorno: se adaptan a los equipos de los desarrolladores y a los procesos de CI/CD, recopilan credenciales tanto como carga útil como mecanismo de propagación, e incluyen comportamientos alternativos para garantizar su propagación o su impacto destructivo. Su detección requiere supervisar el comportamiento en tiempo de ejecución en todas las fases, y no solo un análisis estático del código.
Aspectos técnicos: cómo funciona el tornillo sinfín
| Escenario | ¿Qué pasa? |
|---|---|
| 1. Acceso inicial e implementación | Los atacantes aprovechan cuentas de administradores de npm que han sido comprometidas para distribuir paquetes que contienen setup_bun.js y bun_environment.js, que se ejecuta automáticamente a través de un preinstalación integrarse en los equipos de desarrollo y en los procesos de CI/CD. |
| 2. Inicialización en tiempo de ejecución de forma silenciosa | El cargador detecta el entorno del host, inicializa el tiempo de ejecución de Bun y ejecuta la carga útil de forma silenciosa en segundo plano para que las instalaciones parezcan normales. |
| 3. Análisis del entorno y escalada de privilegios | La carga útil identifica plataformas de infraestructura como servicio (CI), intenta obtener acceso de root sin contraseña a través de Docker en servidores de ejecución de Linux y puede modificar reglas de DNS o de iptables para controlar los flujos de red. |
| 4. Robo de credenciales y claves | La carga útil recopila variables de entorno y claves de la nube, ejecuta TruffleHog para detectar secretos locales, extrae credenciales de AWS, Azure y GCP, e inyecta flujos de trabajo temporales para extraer secretos de GitHub. |
| 5. Exfiltración y persistencia | Los datos robados se codifican mediante triple Base64 y se suben a un nuevo repositorio en la cuenta de la víctima, mientras que la persistencia se establece a través de un ejecutor y un flujo de trabajo maliciosos alojados en un servidor propio. |
| 6. Propagación de gusanos (replicación) | Mediante el uso de tokens de npm robados, el gusano clona los paquetes de la víctima, inyecta archivos y hooks maliciosos, modifica las versiones y los vuelve a publicar para propagarse de forma autónoma. |
| 7. Recurso destructivo | Si no se consiguen obtener credenciales, el gusano activa una rutina destructiva que borra de forma segura el directorio de inicio del usuario. |
Los riesgos de CI/CD puestos de manifiesto por el incidente de PostHog
La filtración de PostHog pone de manifiesto lo sutil que puede ser la exposición de los procesos de CI/CD:
- Las solicitudes de incorporación de cambios maliciosas aprovechaban la función `pull_request_target` en GitHub Actions.
- Se filtró un bot PAT, lo que permitió la publicación de SDK de npm infectados con troyanos.
Los flujos de trabajo de CI/CD, incluso los automatizados, constituyen superficies de ataque de alto riesgo. Limita el uso de scripts, minimiza la exposición de los tokens y exige el uso de credenciales de corta duración.
Limitaciones de las defensas tradicionales
- La fijación de dependencias puede fallar debido a las dependencias transitivas.
- Los escáneres SCA estáticos no pueden detectar código troyanizado de nueva publicación que se oculte bajo nombres de paquetes legítimos.
- El uso indebido de tokens a través de los procesos de CI/CD supone un riesgo incluso para los repositorios internos.
Cómo utilizar la SBOM y Supply Chain como medida de protección
Las herramientas de SBOM y de la cadena de suministro pueden ofrecer:
- Transparencia de las dependencias: realiza un seguimiento de las dependencias directas y transitivas con metadatos sobre la versión y el responsable del mantenimiento.
- Verificación de la procedencia: detecta cambios inesperados en los paquetes o responsables desconocidos.
- Supervisión de credenciales y claves secretas: detecta intentos de sustracción de datos o el uso indebido de tokens.
- Análisis de comportamiento: supervisa el acceso a los recursos o los patrones de ejecución inusuales durante las instalaciones.
Aunque no es una solución milagrosa, combinar la SBOM con la supervisión continua refuerza las defensas contra los ataques de tipo gusano.
OPSWAT y MetaDefender Software Supply ChainChain™
La tecnología OPSWAT analiza el repositorio de código fuente y detecta el paquete malicioso «npm sha1-hulud».
MetaDefender Software Supply Chain ofrece una visión más completa y detecta el paquete sha1-hulud comprometido.
Nuestra base de datos detecta los paquetes comprometidos que se utilizan en los proyectos de los desarrolladores:
Metascan Multiscanning incorpora múltiples niveles de protección para detectar malware:
Medidas inmediatas recomendadas
- Renueva las credenciales: PAT de GitHub, tokens de npm, claves SSH y credenciales de la nube; activa la autenticación de dos factores (MFA).
- Elimina los paquetes comprometidos: borra la caché de npm y el directorio `node_modules`, y fija versiones limpias y fiables.
- Revisar GitHub y CI/CD: buscar nuevos repositorios, flujos de trabajo y confirmaciones sospechosas.
- Reforzar la seguridad de los sistemas: restringir los scripts de ciclo de vida, limitar el acceso a la red de salida y reducir al mínimo el alcance de los tokens.
- Supervisión continua: Tratar las dependencias y las cadenas de trabajo como parte de la superficie de ataque crítica.
Puntos clave
Las amenazas a la cadena de suministro no dependen del ecosistema
La propagación de Shai-Hulud 2.0 a Maven/Java a través del puente npm-to-Maven demuestra que los ataques a la cadena de suministro pueden traspasar las fronteras entre lenguajes y ecosistemas. Incluso los proyectos que no utilizan npm directamente pueden verse expuestos si se emplean herramientas de puente automatizadas.
La gestión de credenciales es fundamental
Los tokens robados (GitHub, npm, nube) permiten la propagación y el acceso a entornos confidenciales. Utiliza tokens de corta duración y de ámbito limitado, exige la autenticación de dos factores (MFA) y renueva las credenciales inmediatamente tras cualquier sospecha de vulneración. Utiliza herramientas automatizadas de análisis de secretos para agilizar el proceso.
Supply Chain integral Supply Chain es imprescindible
No basta con confiar únicamente en el análisis estático de la cadena de suministro de software (SCA) o en la fijación de versiones. Combina la visibilidad de la lista de componentes de software (SBOM), el análisis múltiple de malware y la protección de tokens y secretos para reducir la exposición en todos los ecosistemas. Descubre MetaDefender Software Supply Chain
¿Está listo para proteger su cadena de suministro de software y prevenir ciberataques con soluciones personalizadas y perfectamente integradas?
