Malware Shai Hulud v2

La segunda ola del ataque a la cadena de suministro Shai-Hulud ha penetrado en el ecosistema Maven, tras la vulneración de más de 830 paquetes en el registro de npm. Los investigadores identificaron un paquete de Maven Central, org.mvnpm:posthog-node:4.18.1, que contiene los mismos componentes maliciosos que los ataques anteriores de npm: el cargador setup_bun.js y la carga útil bun_environment.js. Actualmente, este es el único paquete Java conocido afectado.

Cabe destacar que el paquete Maven no fue publicado por PostHog. En su lugar, se generó mediante un proceso automatizado mvnpm que reconstruye los paquetes npm como artefactos Maven. Maven Central confirmó que todas las copias reflejadas se eliminaron el 25 de noviembre de 2025 y que se están implementando protecciones adicionales para evitar que los componentes npm comprometidos se vuelvan a publicar.

Impacto global de los desarrolladores y objetivos de ataque

Esta última ola se dirige a desarrolladores de todo el mundo, con el objetivo de robar datos confidenciales como:

• Claves API
• Credenciales en la nube
• Tokens de npm y GitHub

También facilita una mayor vulnerabilidad de la cadena de suministro mediante un mecanismo autorreplicante similar a un gusano. Esta versión de Shai-Hulud es más sigilosa, agresiva y destructiva que la variante inicial de septiembre. Al comprometer las cuentas de los mantenedores de npm, los atacantes pueden publicar paquetes troyanizados que abren puertas traseras en los equipos de los desarrolladores y escanean automáticamente en busca de secretos para exfiltrarlos a los repositorios de GitHub.

Cómo funciona el malware: flujos de trabajo duales y técnicas ocultas

El ataque aprovecha dos flujos de trabajo maliciosos:

• Registro de ejecutores autohospedados: permite la ejecución de comandos arbitrarios siempre que se abre una discusión de GitHub.
• Flujo de trabajo de recolección de secretos: recopila credenciales sistemáticamente y las envía a GitHub.
• Las mejoras clave en Shai-Hulud v2 incluyen:
• Uso del entorno de ejecución de Bun para ocultar la lógica central
• Ampliación del límite de infección de 20 a 100 paquetes
• Repositorios de exfiltración aleatorios en GitHub para evadir la detección

Hasta el momento, más de 28.000 repositorios se han visto afectados, lo que demuestra la magnitud y el sigilo de la campaña.

Vulnerabilidades explotadas y mecanismos de la cadena de suministro

Los actores de amenazas se han aprovechado de las configuraciones incorrectas de CI en los flujos de trabajo de GitHub Actions, en particular los activadores pull_request_target y workflow_run. Un solo flujo de trabajo mal configurado puede convertir un repositorio en un "paciente cero", lo que facilita la rápida propagación de código malicioso.

El ataque se dirigió a proyectos asociados con AsyncAPI, PostHog y Postman, continuando una campaña más amplia que comenzó con el ataque S1ngularity de agosto de 2025, que afectó a varios paquetes Nx en npm.

Las consecuencias: secretos filtrados y riesgo sistémico

El análisis de la campaña muestra:

• Se filtraron cientos de tokens de acceso de GitHub y credenciales de nube de AWS, Google Cloud y Microsoft Azure.
• Se cargaron más de 5.000 archivos con secretos en GitHub.
• De 11.858 secretos únicos identificados en 4.645 repositorios, 2.298 seguían siendo válidos y expuestos públicamente al 24 de noviembre de 2025.

Esto demuestra cómo un único mantenedor comprometido puede desencadenar un efecto cascada, infectando miles de aplicaciones posteriores.

Recomendaciones para desarrolladores

Para mitigar la exposición, los desarrolladores deben:

• Rotar todas las claves API, tokens y credenciales
• Auditar y eliminar dependencias comprometidas
• Reinstalar versiones limpias del paquete
• Fortalezca los entornos CI/CD con acceso con privilegios mínimos, escaneo de secretos y aplicación automatizada de políticas.

Shai-Hulud subraya que la cadena de suministro de software moderna sigue siendo muy vulnerable. Los atacantes siguen explotando las deficiencias en la publicación, el empaquetado y la implementación del software de código abierto, a menudo sin recurrir a vulnerabilidades de día cero. La defensa más eficaz requiere replantear cómo se crea, se comparte y se consume el software.