La segunda ola del ataque a la cadena de suministro Shai-Hulud se extendió al ecosistema Maven después de comprometer más de 830 paquetes en el registro npm.
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 tanto en los ecosistemas JavaScript/npm como Java/Maven, impulsadas por la misma carga útil Shai Hulud v2», dijo la compañía de ciberseguridad en una actualización del martes.
Vale la pena señalar que el paquete Maven Central no lo publica PostHog. Más bien, las coordenadas «org.mvnpm» se generan mediante un proceso mvnpm automatizado que reconstruye paquetes npm como artefactos Maven. Maven Central dijo que están trabajando para implementar 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 cuando 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, y facilitar un compromiso más profundo de la cadena de suministro en forma de gusano. La última versión también ha evolucionado para ser más sigilosa, agresiva, escalable y destructiva.
Además de tomar prestada la cadena de infección general de la variante inicial de septiembre, el ataque 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 integrado abre puertas traseras a sus propias máquinas, escanea en busca de 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 máquina víctima como un ejecutor autohospedado y permite la ejecución de comandos arbitrarios cada vez que se abre una discusión de GitHub. Un segundo flujo de trabajo está diseñado para recolectar sistemáticamente todos los secretos. Más de 28.000 repositorios se han visto afectados por el incidente.
«Esta versión mejora significativamente el sigilo al utilizar el tiempo de ejecución de 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, exfiltrando datos robados a repositorios públicos de GitHub nombrados aleatoriamente en lugar de uno único codificado».
Los ataques ilustran lo trivial que es para los atacantes aprovechar vías confiables de distribución de software para impulsar versiones maliciosas a escala y comprometer a miles de desarrolladores posteriores. Es más, la naturaleza de autorreplicación del malware significa que una sola cuenta infectada es suficiente para amplificar el radio de explosión del ataque y convertirlo en un brote generalizado en un corto lapso de tiempo.
Un análisis más detallado realizado por Aikido ha descubierto 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 flowwork_run, en los flujos de trabajo existentes de GitHub Actions para llevar a cabo el ataque y comprometer proyectos asociados con AsyncAPI, PostHog y Postman.
La vulnerabilidad «utilizaba el arriesgado disparador pull_request_target de una manera que permitía que el código proporcionado por cualquier 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 un paciente cero para un ataque de rápida propagación, dándole al adversario la capacidad de enviar código malicioso a través de canales automatizados en los que usted confía todos los días».
Se evalúa que la actividad es la continuación de un conjunto más amplio de ataques dirigidos al ecosistema que comenzó con la campaña S1ngularity de agosto de 2025 y afectó a varios paquetes Nx en npm.
«Como una ola nueva y significativamente más agresiva de malware de cadena de suministro npm, Shai-Hulud 2 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 muestra cómo un solo ataque en una biblioteca popular puede afectar a miles de aplicaciones posteriores mediante la troyanización de paquetes legítimos durante la instalación».
Los datos compilados por GitGuardian, OX Security y Wiz muestran que la campaña ha filtrado cientos de tokens de acceso a GitHub y credenciales asociadas con Amazon Web Services (AWS), Google Cloud y Microsoft Azure. Se cargaron más de 5.000 archivos en GitHub con los secretos exfiltrados. El análisis de GitGuardian de 4.645 repositorios de GitHub ha identificado 11.858 secretos únicos, de los cuales 2.298 seguían siendo válidos y expuestos públicamente al 24 de noviembre de 2025.
Se recomienda a los usuarios rotar todos los tokens y claves, auditar todas las dependencias, eliminar las versiones comprometidas, reinstalar paquetes limpios y reforzar 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», afirmó Dan Lorenc, cofundador y director ejecutivo de Chainguard. «Un único mantenedor comprometido y un script de instalación malicioso es todo lo que se necesita para propagar 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 cómo se publica, empaqueta e incorpora el software de código abierto a los sistemas de producción. La única defensa real es cambiar la forma en que se construye y consume el software».