La segunda ola del Ataque a la cadena de suministro de Shai-Hulud se ha extendido al ecosistema de Maven tras comprometer más de 830 paquetes del registro de npm.
El equipo de investigación de Socket dijo que había identificado un paquete de 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 los lanzamientos en los ecosistemas Javascript/NPM y Java/Maven, impulsados por la misma carga útil de Shai Hulud v2", dijo la empresa de ciberseguridad dijo en una actualización del martes.
Vale la pena señalar que el paquete de Maven Central no es publicado por la propia PostHog. Más bien, el «org.mvnpm» coordina se generan a través de un sistema automatizado proceso mvnpm que reconstruye los paquetes npm como artefactos de Maven. Maven Central dijo que están trabajando para implementar protecciones adicionales para evitar que los componentes npm comprometidos ya conocidos se vuelvan a agrupar. A partir del 25 de noviembre de 2025 a las 22:44 UTC, se eliminaron todas las copias reflejadas.
La evolución se produce cuando la «segunda venida» del incidente de la cadena de suministro dirigido desarrolladores de todo el mundo con el objetivo de robar datos confidenciales como claves de API, credenciales de nube y tokens npm y GitHub, y facilitar un compromiso más profundo de la cadena de suministro de forma similar a la de un 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 desarrolladores desprevenidos descargan y ejecutan estas bibliotecas, el código malintencionado incrustado bloquea 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 máquina víctima como un ejecutor autohospedado y permite la ejecución arbitraria de comandos cada vez que se abre un GitHub Discussion. Un segundo flujo de trabajo está diseñado para recopilar sistemáticamente todos los secretos. El incidente ha afectado a más de 28 000 repositorios.
«Esta versión mejora significativamente el sigilo al utilizar el tiempo de ejecución de Bun para ocultar su lógica principal 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 dijo . «También utiliza una nueva técnica de evasión, que filtra los datos robados a repositorios públicos de GitHub con nombres aleatorios en lugar de a uno único y codificado».
Los ataques ilustran lo trivial que resulta para los atacantes aprovechar las vías de distribución de software confiables para lanzar versiones maliciosas a gran escala y comprometer a miles de desarrolladores intermedios. Además, la naturaleza autorreplicante del malware significa que una sola cuenta infectada es suficiente para amplificar el radio de ataque y convertirlo en un brote generalizado en un breve espacio de tiempo.
Un análisis más detallado realizado por Aikido ha descubierto que los actores de amenazas explotaron las vulnerabilidades, centrándose específicamente en las configuraciones erróneas de la 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 los proyectos asociados con AsyncAPI, PostHog y Postman.
La vulnerabilidad «utilizaba el arriesgado disparador pull_request_target de manera que permitía ejecutar el código suministrado por cualquier nueva solicitud de extracción durante la ejecución de la CI», afirma el investigador de seguridad Ilyas Makari. «Un solo error de configuración puede convertir un repositorio en un paciente cero para un ataque que se propague rápidamente, lo que permite al adversario introducir código malintencionado a través de canales automatizados en los que confía todos los días».
Se considera que la actividad es la continuación de un conjunto más amplio de ataques dirigidos al ecosistema que comenzaron en agosto de 2025. Campaña de singularidad afectando a varios paquetes de Nx en npm.
«Como una ola nueva y significativamente más agresiva de malware para la cadena de suministro de npm, Shai-Hulud 2 combina la ejecución sigilosa, la amplitud de las credenciales y un comportamiento destructivo alternativo, lo que lo convierte en uno de los ataques a la cadena de suministro más impactantes del año», dijo Nadav Sharkazy, director de producto de Apiiro , dijo en un comunicado.
«Este malware muestra cómo una sola vulnerabilidad de una biblioteca popular puede repercutir en miles de aplicaciones posteriores al troyanizar paquetes legítimos durante la instalación».
Datos compilados por Guardián de Git , Seguridad OX , y Wiz muestra que la campaña ha filtrado cientos de credenciales y tokens de acceso a GitHub asociados a Amazon Web Services (AWS), Google Cloud y Microsoft Azure. Se subieron más de 5000 archivos a GitHub con los secretos filtrados. El análisis realizado por GitGuardian de 4.645 repositorios de GitHub ha identificado 11.858 secretos únicos, de los cuales 2.298 seguían siendo válidos y estaban expuestos públicamente el 24 de noviembre de 2025.
Los usuarios son aconsejado para rotar todos los tokens y claves, auditar todas las dependencias, eliminar las versiones comprometidas, reinstalar paquetes limpios y reforzar los entornos de desarrolladores y de CI/CD con un acceso con privilegios mínimos, análisis de secretos y aplicación automática de políticas.
«Sha1-Hulud es otro recordatorio de que la cadena de suministro de software moderna sigue siendo demasiado fácil de romper», dijo Dan Lorenc, cofundador y director ejecutivo de Chainguard. «Un único responsable de mantenimiento comprometido y un script de instalación malintencionado es suficiente para llevar a cabo miles de proyectos posteriores en cuestión de horas».
«Las técnicas que utilizan los atacantes evolucionan constantemente. La mayoría de estos ataques no se basan en la tecnología de día cero. Aprovechan las brechas en la forma en que el software de código abierto se publica, empaqueta e incorpora a los sistemas de producción. La única defensa real es cambiar la forma en que se crea y consume el software».