El gusano Shai-Hulud, inicialmente asociado casi en exclusiva al ecosistema npm, ha sido detectado también en el repositorio Maven Central, pieza clave del ecosistema Java. Este movimiento confirma la expansión de una campaña de ataque a la cadena de suministro de software que afecta tanto a desarrolladores JavaScript como Java.
Shai-Hulud en Maven Central: cómo llega el malware al ecosistema Java
Investigadores de Socket identificaron en Maven Central el artefacto org.mvnpm:posthog-node:4.18.1 con dos componentes característicos de Shai-Hulud: el cargador setup_bun.js y el payload principal bun_environment.js. Se trata de los mismos archivos observados en la segunda ola de ataques en paquetes npm.
No se vio comprometido el proyecto Java original, sino un paquete generado automáticamente por mvnpm, herramienta que recompila paquetes npm para publicarlos como artefactos Maven. En la práctica, el código malicioso “viajó” al ecosistema Java a través de este mecanismo de espejado automático de dependencias JavaScript, lo que expone el riesgo de confiar ciegamente en procesos de empaquetado y replicación.
Responsables de Maven Central han indicado que están implantando controles adicionales para bloquear la reempaquetación de componentes npm ya comprometidos, con el objetivo de frenar la propagación de artefactos maliciosos hacia proyectos Java empresariales y de código abierto.
Evolución de Shai-Hulud v2 y objetivos: robo masivo de secretos
Los análisis confirman que el proyecto PostHog fue comprometido tanto en npm como en Maven mediante el mismo payload, identificado como Shai-Hulud versión 2. Esta variante introduce mejoras de sigilo y está orientada específicamente a la exfiltración de secretos de desarrolladores y equipos DevOps.
Según informes de Wiz y otros participantes en la investigación, la campaña alcanzó una escala significativa: hasta el 24 de noviembre de 2025 se habían detectado más de 25 000 repositorios de GitHub que contenían secretos robados, con un crecimiento aproximado de 1000 nuevos repositorios cada 30 minutos. Estas cifras ilustran la velocidad con la que un incidente en la cadena de suministro puede degradar la postura de seguridad global.
Análisis técnico del malware: setup_bun.js y bun_environment.js
Expertos de Step Security describen Shai-Hulud como un malware de dos etapas. El archivo setup_bun.js actúa como dropper, haciéndose pasar por un instalador legítimo de la plataforma Bun. Una vez ejecutado, descarga y lanza el payload principal bun_environment.js, un archivo de alrededor de 10 MB fuertemente ofuscado.
El payload contiene una cadena codificada en hexadecimal con miles de fragmentos de código, un bucle dedicado a entorpecer el análisis estático y una función ofuscada que reconstruye secuencialmente cada porción. Este diseño busca evadir herramientas tradicionales de análisis, antivirus y soluciones de Software Composition Analysis (SCA), que pueden tener dificultades para detectar el comportamiento malicioso.
Tras su ejecución, Shai-Hulud despliega una cadena de ataque en varias fases centrada en el robo de secretos: tokens de GitHub y npm, así como credenciales de AWS, Google Cloud y Microsoft Azure. Si el gusano no logra completar cuatro pasos claves (autenticación en GitHub, creación de un repositorio, detección de tokens de GitHub y npm), cambia de táctica y entra en una fase más destructiva, en la que puede sobrescribir el contenido del directorio personal de la víctima.
Abuso de GitHub Actions y fallos de configuración en CI/CD
Aikido Security señala que los atacantes sacaron partido de configuraciones inseguras en pipelines CI/CD ejecutados con GitHub Actions. En particular, se explotaron flujos con los triggers pull_request_target y workflow_run, que en muchos proyectos estaban configurados de forma laxa, permitiendo el acceso a tokens con privilegios elevados y la ejecución de código arbitrario en repositorios ajenos.
Estos errores de configuración facilitaron la intrusión en proyectos de alto perfil de código abierto, como AsyncAPI, Postman y PostHog. Los secretos robados se publicaban automáticamente en repositorios de GitHub con la descripción “Sha1-Hulud: The Second Coming”, lo que permitía a los atacantes centralizar y reutilizar de forma sistemática estas credenciales comprometidas.
Estimaciones de GitGuardian, OX Security y Wiz apuntan a la filtración de cientos de tokens de GitHub y múltiples credenciales de proveedores cloud. Se identificaron más de 5000 archivos con secretos robados subidos a GitHub, y el análisis de 4645 repositorios reveló 11 858 secretos únicos, de los cuales 2298 seguían activos y accesibles públicamente a 24 de noviembre de 2025.
Medidas de ciberseguridad para proteger la cadena de suministro de software
El caso Shai-Hulud refuerza la necesidad de tratar la seguridad de la cadena de suministro de software como un pilar central de la estrategia de ciberseguridad. Es recomendable revisar los modelos de confianza en repositorios de paquetes y sistemas de espejado automático, implementar SCA con listas de bloqueo de artefactos comprometidos y establecer procesos formales de aprobación de dependencias críticas.
En entornos CI/CD, especialmente con GitHub Actions, conviene aplicar el principio de mínimo privilegio: limitar tokens por flujo de trabajo, desactivar permisos innecesarios, evitar el uso de pull_request_target y otros triggers sensibles sin validación previa, e incorporar revisiones de seguridad específicas para workflows que interactúan con repositorios externos.
Las organizaciones deberían, además, desplegar escáneres de secretos en repositorios y registros de CI, automatizar la rotación de credenciales comprometidas y monitorizar continuamente el uso de tokens y claves de acceso. La combinación de detección temprana, hardening de pipelines y gestión rigurosa de secretos reduce de forma significativa el impacto potencial de campañas similares.
La expansión de Shai-Hulud desde npm hasta Maven Central demuestra que ningún ecosistema está aislado y que las dependencias transitivas pueden convertirse en un vector de alto impacto. Es un momento oportuno para auditar pipelines, reforzar controles en repositorios y adoptar prácticas de seguridad de la cadena de suministro antes de que la próxima ola de ataques vuelva a poner a prueba la resiliencia de los procesos de desarrollo.
