La segunda ola del ataque a la cadena de suministro de Shai-Hulud se extendió al ecosistema de Maven después de comprometer más de 830 paquetes en el registro npm.
El equipo de investigación de Socket dijo que ha identificado un paquete Maven Central llamado org.mvnpm:posthog-node:4.18.1 que incluye los mismos dos componentes relacionados con Sha1-Hulud: el cargador «setup_bun.js» y la carga principal «bun_environment.js».
«Esto significa que el proyecto PostHog ha comprometido versiones tanto en los ecosistemas JavaScript/npm como Java/Maven con la misma carga útil Shai Hulud v2», dijo la firma de ciberseguridad en una actualización el martes.
Tenga en cuenta que PostHog no publica los paquetes de Maven Central. Más bien, las coordenadas «org.mvnpm» se generan a través de un proceso mvnpm automatizado que reconstruye paquetes npm como artefactos Maven. Maven Central dijo que está trabajando en la implementación de protecciones adicionales para evitar que se vuelvan a agrupar componentes npm ya conocidos y comprometidos. A partir del 25 de noviembre de 2025 a las 22:44 UTC, se eliminaron todas las copias reflejadas.
El desarrollo se produce como un «resurgimiento» de incidentes en la cadena de suministro dirigidos a desarrolladores de todo el mundo con el objetivo de robar datos confidenciales como claves API, credenciales de nube, npm y tokens de GitHub, y facilitar compromisos más profundos de la cadena de suministro en forma de gusano. La última versión ha evolucionado para ser más sigilosa, agresiva, escalable y destructiva.
Además de tomar prestada toda la cadena de infección de la variante original de septiembre, este ataque también permite a los atacantes obtener acceso comprometido a cuentas de mantenimiento de npm y publicar versiones troyanizadas de paquetes. Cuando un desarrollador desprevenido descarga y ejecuta estas bibliotecas, el código malicioso incorporado abre una puerta trasera en su máquina, busca secretos y utiliza tokens robados para filtrarlos a un repositorio de GitHub.
El ataque logra esto inyectando dos flujos de trabajo maliciosos. Uno de ellos registra la máquina de la víctima como un ejecutor autohospedado, lo que le permite ejecutar comandos arbitrarios cada vez que se abre una discusión de GitHub. El segundo flujo de trabajo está diseñado para recopilar todos los secretos de forma sistemática. Este incidente afectó a más de 28.000 repositorios.
Ronen Slavin y Roni Kuznicki de Cycode dijeron: «Esta versión mejora significativamente el sigilo al utilizar el tiempo de ejecución de Bun para ocultar la lógica central y aumenta la escala potencial al aumentar el límite de infección de 20 a 100 paquetes». «También se utilizan nuevas técnicas de evasión para filtrar datos robados en repositorios públicos de GitHub con nombres aleatorios en lugar de un único repositorio de GitHub codificado».
Este ataque muestra lo fácil que es para los atacantes aprovechar los canales de distribución de software confiables para impulsar versiones maliciosas a escala, poniendo en riesgo a miles de desarrolladores intermedios. Además, debido a la naturaleza autorreplicante de este malware, incluso una sola cuenta infectada puede aumentar el alcance del ataque, lo que podría provocar un brote generalizado en un corto período de tiempo.
Un análisis más detallado realizado por Aikido reveló que los actores de amenazas explotaron vulnerabilidades y se centraron específicamente en configuraciones erróneas de CI en los flujos de trabajo pull_request_target y flowwork_run de los flujos de trabajo de GitHub Actions existentes para realizar ataques y comprometer proyectos relacionados con AsyncAPI, PostHog y Postman.
El investigador de seguridad Ilyas Makari dijo que la vulnerabilidad «aprovechó un peligroso disparador pull_request_target para permitir que el código proporcionado por una nueva solicitud de extracción se ejecutara durante una ejecución de CI». «Una sola configuración incorrecta puede convertir un repositorio en el paciente cero de un ataque que se propaga rápidamente, permitiendo a los atacantes enviar código malicioso a través de los canales automatizados en los que confían habitualmente».
Esta actividad se evalúa como una continuación de una serie más amplia de ataques dirigidos al ecosistema, comenzando con la campaña S1ngularity en agosto de 2025 que afectó a varios paquetes Nx en npm.
«Shai-Hulud 2 es una ola nueva y altamente agresiva de malware de cadena de suministro npm que combina ejecución sigilosa, amplia gama de credenciales y comportamiento destructivo con respaldo, lo que lo convierte en uno de los ataques a la cadena de suministro de mayor impacto este año», dijo Nadav Sharkazy, gerente de producto de Apiiro, en un comunicado.
«Al troyanizar paquetes legítimos durante la instalación, este malware demuestra cómo el compromiso de una biblioteca popular puede propagarse a miles de aplicaciones posteriores».
Los datos compilados por GitGuardian, OX Security y Wiz muestran que la campaña comprometió cientos de tokens de acceso y credenciales de GitHub relacionados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure. Se cargaron en GitHub más de 5.000 archivos que contenían secretos filtrados. El análisis de GitGuardian de 4.645 repositorios de GitHub identificó 11.858 secretos únicos, de los cuales 2.298 siguen siendo válidos y disponibles públicamente al 24 de noviembre de 2025.
Recomendamos que los usuarios roten todos los tokens y claves, auditen todas las dependencias, eliminen las versiones comprometidas, reinstale paquetes limpios y refuercen sus entornos de desarrollador y CI/CD con acceso con privilegios mínimos, escaneo secreto y aplicación automática de políticas.
«Sha1-Hulud es otro recordatorio de que las cadenas de suministro de software modernas todavía son demasiado fáciles de romper», afirmó Dan Lorenc, cofundador y director ejecutivo de Chainguard. «Solo se necesita un mantenedor comprometido y un script de instalación malicioso para propagarse a miles de proyectos posteriores en cuestión de horas».
«Las técnicas utilizadas por los atacantes están en constante evolución. La mayoría de estos ataques no se basan en días cero. Explotan las brechas en la forma en que se publica, empaqueta e incorpora el software de código abierto en los sistemas de producción. La única defensa real es cambiar la forma en que se construye y utiliza el software».
Source link
