Mini Shai-Hulud, vinculado al grupo TeamPCP, se ha convertido en uno de los gusanos más peligrosos en los ecosistemas npm y PyPI: ha comprometido los paquetes TanStack, UiPath, Mistral AI, OpenSearch y Guardrails AI, publicando versiones maliciosas a través de GitHub Actions legítimos con firma SLSA válida y propagándose después automáticamente a otros paquetes del mismo mantenedor; los desarrolladores y las empresas que utilizan estos ecosistemas deben revisar de inmediato las versiones empleadas, revocar los tokens de npm/GitHub y comprobar la infraestructura de CI/CD en busca de signos de compromiso.

Detalles técnicos del ataque de Mini Shai-Hulud

El vector principal en el ecosistema de TanStack es una cadena de ataques contra GitHub Actions. Según el equipo de TanStack, los atacantes utilizaron tres elementos clave: el trigger pull_request_target, el envenenamiento de la caché de GitHub Actions y la extracción de un token OIDC de la memoria del proceso del runner en la fase de ejecución (postmortem de TanStack; investigación sobre la caché de GitHub Actions — Adnan Khan).

Los pasos posteriores del ataque contra TanStack fueron los siguientes:

• preparación de un payload malicioso en un fork del proyecto en GitHub;
• inyección de archivos maliciosos en los tarball publicados de los paquetes npm;
• toma de control del workflow legítimo TanStack/router mediante el token OIDC robado y publicación de versiones comprometidas a través de la cadena oficial de releases.

Como resultado, se publicaron versiones maliciosas de 42 paquetes (84 versiones) en el ecosistema de TanStack; al incidente se le ha asignado el identificador CVE-2026-45321 con una puntuación CVSS 9.6, lo que se refleja en el advisory del proyecto en GitHub (GitHub Security Advisory) y en la base de datos NVD (NVD CVE-2026-45321).

El componente clave del código malicioso en los paquetes npm es el archivo JavaScript ofuscado router_init.js, que:

• perfilera el entorno de ejecución (sistema operativo, contexto de ejecución, herramientas de desarrollo);
• lanza un ladrón de credenciales multifuncional, dirigido a proveedores cloud, monederos de criptomonedas, herramientas de trabajo con IA, mensajería y sistemas de CI, incluidos GitHub Actions;
• exfiltra datos al dominio filev2.getsession[.]org, perteneciente al mensajero descentralizado Session, lo que reduce la probabilidad de bloqueo del tráfico en redes corporativas;
• como canal de reserva, realiza commits de datos cifrados en repositorios controlados por los atacantes a través de GitHub GraphQL API utilizando tokens de GitHub robados; el autor de los commits se disfraza como [email protected].

Para mantener la persistencia en el sistema, el malware se integra en las IDE Claude Code y Visual Studio Code, de modo que el ladrón de credenciales se ejecute en cada inicio del entorno de desarrollo. Además, se instala el servicio gh-token-monitor para monitorizar y volver a exfiltrar tokens de GitHub, y se añaden dos workflow maliciosos de GitHub Actions que serializan los secretos del repositorio a JSON y los envían al servidor api.masscan[.]cloud.

Una característica distintiva del gusano es su capacidad de autorreplicación en el ecosistema npm. El código malicioso:

• busca un token de publicación de npm con el flag bypass_2fa=true;
• enumera todos los paquetes publicados por el mismo mantenedor;
• a través del token OIDC de GitHub robado, obtiene tokens de publicación individuales para cada paquete, eludiendo los mecanismos tradicionales de autenticación.

Los paquetes npm comprometidos se distribuyen con atestaciones SLSA Build Level 3 válidas, es decir, el ataque demostró por primera vez la posibilidad de publicar compilaciones maliciosas, pero formalmente «demostrablemente reproducibles», a través de una cadena de confianza (análisis de StepSecurity).

Ampliación de la campaña más allá de TanStack

El gusano Mini Shai-Hulud ha ido más allá de TanStack y ha afectado a otros proyectos y ecosistemas, incluido PyPI. Se han confirmado los siguientes paquetes y versiones comprometidos:

• [email protected] (PyPI)
• [email protected] (PyPI)
• @opensearch-project/opensearch: 3.5.3, 3.6.2, 3.7.0, 3.8.0
• @squawk/[email protected]
• @squawk/[email protected]
• @squawk/[email protected]
• @tallyui/connector-medusa: 1.0.1, 1.0.2, 1.0.3
• @tallyui/connector-vendure: 1.0.1, 1.0.2, 1.0.3

El análisis de Microsoft sobre el paquete malicioso [email protected] muestra que descarga un ladrón de credenciales desde el host 83.142.209[.]194 y contiene lógica dependiente del país e idioma del sistema: el malware evita entornos de habla rusa y tiene una «rama destructiva limitada geográficamente» con una probabilidad de 1 a 6 de ejecutar rm -rf / cuando considera que el sistema se encuentra en Israel o Irán (análisis de Microsoft Threat Intelligence).

La compromisión de [email protected] es especialmente peligrosa, ya que el código malicioso se ejecuta ya en el momento de importar el módulo. Según el análisis de Socket (análisis de Socket), el paquete:

• comprueba que se está ejecutando en Linux;
• descarga un artefacto desde https://git-tanstack.com/transformers.pyz;
• lo escribe en /tmp/transformers.pyz y lo ejecuta mediante python3 sin ningún tipo de verificación de integridad.

Contexto y características de la amenaza

Al menos tres aspectos convierten a Mini Shai-Hulud en un nuevo nivel cualitativo de amenaza para la cadena de suministro de software:

1. Gusano autorreplicante en el ecosistema npm. El malware no solo compromete un paquete de forma puntual, sino que busca activamente y contagia otros paquetes del mismo mantenedor aprovechando las particularidades de la gestión de tokens de npm y la integración con GitHub OIDC.
2. Abuso de mecanismos de confianza — SLSA y OIDC. Las organizaciones que se basaban en SLSA Build Level 3 y en pipelines «sin secretos» con OIDC como garantía de confianza han recibido un ejemplo claro de que la compromisión del runner y del workflow puede convertir estos mecanismos en un canal de entrega de código malicioso.
3. Evasión heurística y destructividad no trivial. El uso de la infraestructura de Session (dominio getsession[.]org) reduce la probabilidad de bloqueo a nivel de red, y la lógica geodependiente en la versión para mistralai crea una amenaza combinada de espionaje y destrucción selectiva de datos.

El ataque demuestra una comprensión madura por parte de los atacantes de los mecanismos internos de GitHub Actions y la gestión de la caché, tal y como se describió previamente en la investigación sobre envenenamiento de caché (análisis de la caché de GitHub Actions), y muestra que incluso el código «infraestructural» de CI/CD debe considerarse un objeto de protección prioritario.

Evaluación del impacto

Están especialmente expuestos al riesgo:

• los equipos de desarrollo que usan directamente o de forma transitiva (a través de dependencias) TanStack y los paquetes npm/PyPI enumerados arriba;
• las organizaciones en las que GitHub Actions tiene amplios permisos (write sobre repositorios, gestión de releases, asignación de tokens OIDC en cuentas cloud);
• las empresas que utilizan de forma activa herramientas y bibliotecas de IA (Mistral, Guardrails, plugins de IA) y una infraestructura de CI/CD basada en GitHub Actions.

Las posibles consecuencias en ausencia de una reacción incluyen:

• compromiso de la cadena de suministro de software: publicación de versiones maliciosas de bibliotecas internas y aplicaciones a través de pipelines de compilación legítimos;
• fuga de secretos (tokens, contraseñas, claves API) desde GitHub, CI/CD y entornos cloud mediante los workflow implantados y el servicio gh-token-monitor;
• daño directo a la infraestructura, desde acceso no autorizado a repositorios y recursos cloud hasta un posible borrado del sistema de archivos en hosts concretos seleccionados como objetivo;
• riesgos reputacionales y regulatorios, si los clientes o socios resultan afectados a través de cadenas de suministro comprometidas.

Dado el carácter del gusano y la puntuación crítica de CVSS 9.6 para CVE-2026-45321, el incidente debe considerarse de máxima prioridad para todas las organizaciones que dependen de GitHub Actions y de registros públicos de dependencias.

Recomendaciones prácticas

1. Inventario y limpieza de dependencias

• Comprobar de inmediato si en los proyectos se han utilizado las siguientes versiones:
  • todos los paquetes de TanStack afectados según el advisory GHSA-g7cv-rxg3-hmpx;
  • guardrails-ai==0.10.1, mistralai==2.4.6 (PyPI);
  • @opensearch-project/opensearch versiones 3.5.3, 3.6.2, 3.7.0, 3.8.0;
  • @squawk/[email protected], @squawk/[email protected], @squawk/[email protected];
  • @tallyui/connector-medusa y @tallyui/connector-vendure versiones 1.0.1–1.0.3.
• Revisar los archivos de bloqueo (package-lock.json, pnpm-lock.yaml, poetry.lock, requirements.txt) y los logs de compilación de CI, y no solo la configuración actual de dependencias.
• Para las versiones maliciosas detectadas:
  • actualizar de inmediato a versiones corregidas o hacer rollback a releases conocidos como seguros;
  • recompilar y volver a desplegar las aplicaciones afectadas.

2. Verificación de indicios de compromiso

• En los logs de red y proxy: buscar solicitudes a
  • filev2.getsession[.]org,
  • api.masscan[.]cloud,
  • 83.142.209[.]194,
  • git-tanstack.com/transformers.pyz.
• En el sistema de archivos de las máquinas de desarrollo y los runners de CI:
  • presencia de router_init.js fuera del contexto esperado;
  • rastros de /tmp/transformers.pyz y de ejecuciones de python3 /tmp/transformers.pyz en los logs de shell.
• En GitHub:
  • búsqueda de commits con el autor [email protected]:
    git log --author="[email protected]";
  • auditoría del directorio .github/workflows en busca de workflows añadidos o modificados recientemente, especialmente los que incluyan serialización de secretos y comunicaciones de red con hosts externos;
  • revisión de las extensiones instaladas y actualizadas para VS Code y Claude Code que hayan aparecido en el mismo intervalo temporal que el uso de paquetes comprometidos.

3. Gestión de tokens de npm/GitHub y OIDC

• Revocar y volver a emitir:
  • tokens de publicación de npm, especialmente con el flag bypass_2fa;
  • personal access tokens de GitHub y secretos utilizados en GitHub Actions;
  • roles y políticas de confianza asociadas con tokens OIDC de GitHub en cuentas cloud.
• Restringir el uso del trigger pull_request_target únicamente a los casos en que sea objetivamente necesario; considerar migrar los workflows sensibles a pull_request sin privilegios elevados.
• Endurecer la política de permisos para GitHub Actions:
  • aplicar el principio de privilegio mínimo para GITHUB_TOKEN y para workflows individuales;
  • prohibir la escritura en el repositorio desde workflows que procesen pull requests externos sin validaciones adicionales.

4. Política de confianza en SLSA y en los artefactos de compilación

• Revisar las políticas internas que otorgan automáticamente confianza a paquetes con un «alto nivel» de SLSA u otras atestaciones de provenance: la atestación del origen de la compilación no elimina la necesidad de analizar el contenido.
• Incorporar en el pipeline:
  • análisis estático y dinámico de dependencias;
  • comprobación frente a IOC conocidos y dominios de mando y control;
  • controles de seguridad específicos para artefactos procedentes de repositorios fork o contribuyentes externos.

La conclusión clave para los equipos de desarrollo y seguridad es que Mini Shai-Hulud ha demostrado que los pipelines de compilación de confianza, las atestaciones SLSA y el mecanismo OIDC no son suficientes por sí solos: es necesario auditar de inmediato las dependencias en busca de versiones afectadas, revocar y volver a emitir todos los tokens de npm/GitHub asociados con proyectos y runners comprometidos, y endurecer la configuración de GitHub Actions (limitar pull_request_target y los permisos de los workflows) para cerrar los vectores de propagación demostrados en esta campaña.