La segunda ola del ataque a la cadena de suministro de Shai Hulud se extendió al ecosistema Maven después de que más de 830 paquetes en el registro npm se vieran comprometidos.
El equipo de investigación de Socket dijo que identificó un paquete Maven Central llamado org.mvnpm:posthog-node:4.18.1 que incorpora los mismos dos componentes asociados con Sha1-Hulud: el cargador setup_bun.js y la carga útil principal bun_environment.js.
“Esto significa que el proyecto PostHog ha comprometido versiones en los ecosistemas JavaScript/npm y Java/Maven que funcionan con la misma carga útil Shai Hulud v2”, dijo la firma de ciberseguridad en una actualización el martes.
Vale la pena señalar que PostHog no publica el paquete Maven Central. Más bien, las coordenadas org.mvnpm se generan mediante un proceso mvnpm automatizado que recrea paquetes npm como artefactos Maven. Maven Central dijo que están trabajando para implementar protecciones adicionales para evitar que se vuelvan a agrupar componentes de NPM que ya se conocen y que están comprometidos. El 25 de noviembre de 2025 a las 22:44 UTC, se eliminaron todas las copias reflejadas.
El desarrollo llega en un momento en que la “segunda venida” del incidente de la cadena de suministro se ha dirigido a desarrolladores de todo el mundo, con el objetivo de robar datos confidenciales como claves API, credenciales de nube y tokens npm y GitHub, lo que permite un compromiso más profundo de la cadena de suministro en forma de gusano. La última versión también se ha vuelto más sigilosa, más agresiva, más escalable y más destructiva.
El ataque no sólo aprovecha toda la cadena de infección de la primera variante de septiembre, sino que también permite a los actores de amenazas obtener acceso no autorizado a las cuentas de mantenimiento de npm y publicar versiones troyanizadas de sus paquetes. Cuando los desarrolladores desprevenidos descargan y ejecutan estas bibliotecas, el código malicioso incorporado penetra en sus propias máquinas, busca secretos y los filtra a los repositorios de GitHub utilizando los tokens robados.
El ataque logra esto inyectando dos flujos de trabajo fraudulentos, uno de los cuales registra la computadora de la víctima como un ejecutor autohospedado y permite ejecutar comandos arbitrarios cada vez que se abre una discusión de GitHub. Un segundo flujo de trabajo está destinado a recopilar sistemáticamente todos los secretos. Más de 28.000 repositorios se vieron afectados por el incidente.
“Esta versión mejora significativamente el sigilo al aprovechar el tiempo de ejecución del bun para ocultar su lógica central y aumenta su escala potencial al aumentar el límite de infección de 20 a 100 paquetes”, dijeron Ronen Slavin y Roni Kuznicki de Cycode. “También utiliza una nueva técnica de evasión que filtra los datos robados en repositorios públicos de GitHub nombrados aleatoriamente en lugar de uno único codificado”.
Los ataques resaltan lo trivial que es para los atacantes explotar rutas confiables de distribución de software para difundir versiones maliciosas a escala, poniendo en riesgo a miles de desarrolladores intermedios. Además, la función de autorreplicación del malware significa que una sola cuenta infectada es suficiente para aumentar el radio de explosión del ataque, convirtiéndolo en un brote a gran escala en un corto período de tiempo.
Un análisis más detallado realizado por Aikido reveló que los actores de amenazas explotaron vulnerabilidades, centrándose específicamente en configuraciones erróneas de CI en los flujos de trabajo pull_request_target y Workflow_run en los flujos de trabajo de GitHub Actions existentes, para llevar a cabo el ataque y comprometer proyectos asociados con AsyncAPI, PostHog y Postman.
La vulnerabilidad “explotó el arriesgado disparador pull_request_target de una manera que permitió que el código proporcionado por cada nueva solicitud de extracción se ejecutara durante la ejecución de CI”, dijo el investigador de seguridad Ilyas Makari. “Una sola configuración incorrecta puede convertir un repositorio en una zona cero para un ataque que se propaga rápidamente, brindando al atacante la oportunidad de enviar código malicioso a través de canales automatizados en los que usted confía todos los días”.
Se cree que la actividad es una continuación de una serie más amplia de ataques dirigidos al ecosistema que comenzó con la campaña S1ngularity en agosto de 2025, que afectó a varios paquetes Nx en npm.
“Shai-Hulud 2, una ola nueva y significativamente más agresiva de malware para la cadena de suministro NPM, combina ejecución sigilosa, amplitud de credenciales y comportamiento destructivo de respaldo, lo que lo convierte en uno de los ataques a la cadena de suministro más impactantes del año”, dijo Nadav Sharkazy, gerente de producto de Apiiro, en un comunicado.
“Este malware demuestra cómo un solo compromiso de una biblioteca popular puede generar miles de aplicaciones posteriores al troyanizar paquetes legítimos durante la instalación”.
Los datos compilados por GitGuardian, OX Security y Wiz muestran que la campaña expuso cientos de tokens de acceso y credenciales de GitHub relacionados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure. Se cargaron más de 5.000 archivos en GitHub y se filtraron los secretos. El análisis de GitGuardian de 4.645 repositorios de GitHub identificó 11.858 secretos únicos, de los cuales 2.298 todavía eran válidos y estaban disponibles públicamente al 24 de noviembre de 2025.
Se recomienda a los usuarios rotar todos los tokens y claves, verificar todas las dependencias, eliminar las versiones comprometidas, reinstalar paquetes limpios y fortalecer los entornos de desarrollador y CI/CD con acceso con privilegios mínimos, escaneo secreto y aplicación automatizada de políticas.
“Sha1-Hulud es otro recordatorio de que la cadena de suministro de software moderna todavía es demasiado fácil de romper”, dijo Dan Lorenc, cofundador y director ejecutivo de Chainguard. “Un único mantenedor comprometido y un script de instalación malicioso son suficientes para penetrar miles de proyectos posteriores en cuestión de horas”.
“Las técnicas que utilizan 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 y adopta el software de código abierto en los sistemas de producción. La única defensa real es cambiar la forma en que se crea y consume el software”.
About The Author
