Worm Mini Shai-Hulud compromete paquetes de TanStack, Mistral AI, Guardrails AI y otros proyectos
Los ataques a la cadena de suministro de software están volviéndose cada vez más sofisticados, y la campaña más reciente del grupo TeamPCP es un ejemplo bastante claro de ello.
Bautizada como Mini Shai-Hulud, la ofensiva comprometió paquetes de proyectos como TanStack, Mistral AI, Guardrails AI, UiPath y OpenSearch, además de decenas de otros distribuidos a través de npm y PyPI.
El número asusta: más de 170 paquetes afectados e impresionantes 518 millones de descargas acumuladas en las versiones comprometidas. Al menos 400 repositorios con credenciales robadas fueron creados como parte de la oleada de ataques, todos conteniendo la cadena Shai-Hulud: Here We Go Again.
No es un ataque común.
Estamos ante un worm con capacidad de autoproliferación, que se propaga por toda la cadena sin necesidad de robar tokens de publicación tradicionales, explotando credenciales e infraestructuras de CI/CD legítimas para moverse de un mantenedor a otro de forma casi invisible.
Lo que más llama la atención aquí no es solo la escala, sino la ingeniería detrás del ataque.
Por primera vez en un caso documentado, paquetes maliciosos fueron publicados con procedencia SLSA Build Level 3 válida, ese conjunto de garantías que debería señalar exactamente lo contrario: que el software es confiable y que el proceso de build no fue adulterado.
Múltiples informes de empresas como Aikido Security, Endor Labs, SafeDep, Socket, StepSecurity y Snyk confirmaron los detalles técnicos de la campaña. A lo largo de este artículo, vamos a detallar cómo funcionó todo esto en la práctica, qué proyectos fueron comprometidos, qué hace el malware después de instalado y qué necesitan saber los desarrolladores ahora para proteger sus entornos. 🔍
Cómo se propagó Mini Shai-Hulud por la cadena de suministro
Para entender la gravedad de lo que ocurrió, es necesario comprender la lógica detrás del movimiento de Mini Shai-Hulud. A diferencia de ataques convencionales, donde un agente malicioso necesita comprometer individualmente cada cuenta de mantenedor o robar tokens de autenticación, este worm funciona de manera mucho más inteligente y aterradora. Actúa dentro de entornos de integración continua ya autorizados, aprovechando pipelines de CI/CD que los propios proyectos utilizan en el día a día para construir y publicar versiones. Esto significa que el código malicioso circula con todos los permisos necesarios, sin levantar alarmas inmediatas en los sistemas de detección tradicionales.
El mecanismo de autoproliferación es el punto central de todo. Cuando el worm obtiene acceso al entorno de build de un mantenedor, no se queda quieto. Localiza un token npm publicable con la configuración bypass_2fa definida como true, enumera todos los paquetes publicados por el mismo mantenedor e intercambia un token OIDC de GitHub por un token de publicación específico para cada paquete, eludiendo completamente la autenticación tradicional. A partir de ahí, replica el comportamiento malicioso hacia esos nuevos entornos, publicando versiones comprometidas en registros como npm y PyPI de forma automatizada. Todo este ciclo ocurre sin interacción humana directa, lo que explica la velocidad con la que el ataque alcanzó más de 170 paquetes en un intervalo relativamente corto de tiempo.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La técnica utilizada en el ecosistema TanStack es particularmente ingeniosa. Según el análisis post-mortem publicado por el propio TanStack, el compromiso involucró un ataque encadenado vía GitHub Actions que explotó el disparador pull_request_target, envenenamiento del caché de GitHub Actions y extracción en tiempo de ejecución de un token OIDC directamente de la memoria del proceso runner. Los atacantes prepararon el payload malicioso en un fork de GitHub a través de un commit huérfano, inyectaron el código en los tarballs publicados en npm y luego secuestraron el workflow legítimo del repositorio TanStack/router para publicar las versiones comprometidas con procedencia SLSA válida.
Lo que hace esta campaña aún más preocupante es justamente el hecho de que los paquetes publicados portaban procedencia SLSA Build Level 3 válida. El framework SLSA, que significa Supply Chain Levels for Software Artifacts, fue creado para ofrecer garantías sobre la integridad del proceso de construcción de software. Un paquete con esta certificación debería, en teoría, ser seguro, rastreable y libre de adulteraciones. Pero como el ataque operó dentro de infraestructuras legítimas, logró generar esa procedencia de forma técnicamente correcta, engañando hasta los mecanismos de verificación más rigurosos.
Como explicó el investigador Peyton Kennedy, de Endor Labs, el commit huérfano disparó una ejecución de workflow de GitHub Actions contra la superficie legítima de TanStack/router. Como la configuración de trusted publisher del OIDC otorgaba confianza a nivel del repositorio, sin alcance restringido a una branch protegida o archivo de workflow específico, el workflow disparado por aquel commit logró solicitar un token de publicación npm válido y de corta duración.
Es la primera vez que este tipo de elusión fue documentado a escala real, y esto redefine lo que la comunidad entiende como garantía de seguridad en builds automatizados. 😬
TanStack, Mistral AI y Guardrails AI entre los proyectos comprometidos
El TanStack es uno de los ecosistemas más populares del mundo JavaScript moderno. Proyectos como TanStack Query, TanStack Router y TanStack Table son utilizados por miles de aplicaciones en producción alrededor del mundo, con descargas diarias en el orden de los millones. El compromiso de TanStack recibió el identificador CVE-2026-45321, con una puntuación CVSS de 9.6 sobre 10.0, indicando severidad crítica. El incidente impactó 42 paquetes y 84 versiones en todo el ecosistema TanStack.
Cuando un paquete de este nivel de adopción es comprometido, el impacto potencial va mucho más allá de los números directos de descarga. Los desarrolladores que utilizan estas bibliotecas como dependencias en sus propios proyectos también terminan expuestos sin saberlo, creando un efecto cascada que se multiplica a lo largo de toda la cadena productiva de software.
El equipo de TanStack informó que rastreó el compromiso y confirmó que ningún token npm fue robado directamente, y que el workflow de publicación npm en sí no fue comprometido. El vector de ataque fue la explotación encadenada del sistema de GitHub Actions y OIDC.
El enfoque técnico varió entre los objetivos
Un detalle técnico importante es que el enfoque del ataque varió entre los diferentes objetivos. En el caso de TanStack, a diferencia de la oleada anterior que afectó paquetes SAP, donde los paquetes comprometidos añadían un hook de preinstall para disparar la secuencia de infección, el cluster TanStack adoptó una estrategia diferente. Los paquetes incluían un archivo JavaScript dentro del tarball y añadían una dependencia opcional que apuntaba a un paquete alojado en GitHub. Esa dependencia contenía un hook de ciclo de vida prepare que ejecutaba el payload JavaScript a través del runtime Bun.
Las actualizaciones en los paquetes de Mistral AI siguieron el enfoque anterior, sustituyendo el contenido del archivo package.json con un hook de preinstall para invocar node setup.mjs, que descargaba Bun y ejecutaba el mismo malware JavaScript.
En el caso de Mistral AI, la situación tiene una capa adicional de complejidad. La empresa es una de las más relevantes en el panorama actual de modelos de lenguaje a gran escala, y sus paquetes oficiales son utilizados por desarrolladores que integran capacidades de inteligencia artificial en aplicaciones y servicios. El análisis de Microsoft sobre el paquete malicioso mistralai en PyPI reveló que fue diseñado para descargar un stealer de credenciales desde un servidor remoto e que incluye lógica de reconocimiento por país para evadir entornos en idioma ruso, además de una ramificación destructiva con geofencing que tiene una probabilidad de 1 entre 6 de ejecutar el comando rm -rf / cuando el sistema parece estar en Israel o Irán.
El compromiso de Guardrails AI en la versión 0.10.1 en PyPI es especialmente notable porque el código malicioso se ejecuta al importar. El paquete verifica si está corriendo en sistemas Linux, descarga un artefacto Python remoto, lo guarda en /tmp/transformers.pyz y lo ejecuta con python3 sin ninguna verificación de integridad.
Lista completa de paquetes comprometidos identificados
Además de TanStack y Mistral AI, la campaña se extendió a diversos otros paquetes, incluyendo algunos en PyPI:
- guardrails-ai@0.10.1 (PyPI)
- mistralai@2.4.6 (PyPI)
- @opensearch-project/opensearch@3.5.3, 3.6.2, 3.7.0 y 3.8.0
- @squawk/mcp@0.9.5
- @squawk/weather@0.5.10
- @squawk/flightplan@0.5.6
- @tallyui/connector-medusa@1.0.1, 1.0.2 y 1.0.3
- @tallyui/connector-vendure@1.0.1, 1.0.2 y 1.0.3
Según datos de OX Security, el incidente afectó a más de 170 paquetes en ambos registros npm y PyPI. La diversidad de los objetivos sugiere que la estrategia del grupo no fue enfocarse en un único ecosistema, sino mapear conexiones entre mantenedores y proyectos para maximizar el alcance de cada nuevo punto de entrada conquistado. Este enfoque sistémico es lo que diferencia al Mini Shai-Hulud de campañas anteriores. 🔐
Qué hace el malware después de instalado
Una vez que un paquete comprometido se instala en el entorno de un desarrollador o en un pipeline de CI/CD, el Mini Shai-Hulud comienza a operar en múltiples frentes. Los paquetes npm afectados fueron modificados para incluir un archivo JavaScript ofuscado llamado router_init.js, diseñado para analizar el entorno de ejecución y lanzar un stealer de credenciales integral capaz de apuntar a proveedores de nube, billeteras de criptomonedas, herramientas de IA, aplicaciones de mensajería y sistemas de CI, incluyendo GitHub Actions.
Los datos recopilados se exfiltran hacia el dominio filev2.getsession.org. El uso de la infraestructura del Session Protocol es un intento deliberado de los atacantes para evadir la detección, ya que el dominio difícilmente será bloqueado en entornos corporativos por pertenecer a un servicio de mensajería descentralizado y enfocado en privacidad.
Múltiples mecanismos de persistencia
El malware demuestra un nivel notable de sofisticación en los mecanismos de persistencia que implementa:
- Hooks de persistencia en Claude Code y VS Code: El malware se instala de forma que sobrevive a reinicios del sistema y se vuelve a ejecutar cada vez que los IDEs se inician.
- Servicio gh-token-monitor: Un servicio dedicado que monitorea y re-exfiltra tokens de GitHub de forma continua.
- Workflows maliciosos de GitHub Actions: Dos workflows se inyectan para serializar los secretos del repositorio en un objeto JSON y subir los datos a un servidor externo en api.masscan.cloud.
- Fallback vía GraphQL: Como opción alternativa, los datos cifrados se comitean en repositorios controlados por los atacantes bajo el nombre de autor claude@users.noreply.github.com a través de la API GraphQL de GitHub, usando los tokens robados.
El dead-mans switch: una trampa para quien intenta reaccionar
Uno de los comportamientos más agresivos e inéditos introducidos en esta campaña es la instalación de un dead-mans switch. Se trata de un shell script que verifica periódicamente si un token npm creado por el malware no ha sido revocado, consultando el endpoint api.github.com/user cada 60 segundos. El token posee la descripción provocativa IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.
Si el desarrollador revoca el token desde el panel de npm, el script dispara una rutina destructiva que ejecuta rm -rf ~/ en la máquina infectada, transformando esencialmente el malware en un wiper. Estos cambios indican que TeamPCP se está volviendo más agresivo y está evolucionando sus técnicas con cada nueva campaña.
Esto es extremadamente importante: los desarrolladores no deben revocar los tokens npm antes de aislar y crear una imagen forense del sistema. Reaccionar precipitadamente puede resultar en la destrucción completa de los datos de la máquina. 🚨
Herramientas que usamos a diario
Por qué este ataque cambia las reglas del juego
El grupo TeamPCP demostró un nivel de sofisticación técnica que va más allá de lo que se veía en campañas anteriores de ataques a la cadena de suministro. La combinación entre autoproliferación, uso de infraestructuras legítimas y generación de procedencia SLSA válida crea un escenario donde las defensas tradicionales simplemente no son suficientes. Las herramientas de escaneo de vulnerabilidades que dependen de firmas conocidas no detectan el problema porque el código malicioso llega envuelto en procesos técnicamente correctos.
Como destacó el investigador Ashish Kurmi, de StepSecurity, el ataque publicó versiones maliciosas a través del propio pipeline de release de GitHub Actions del proyecto, usando tokens OIDC secuestrados. En una escalada extremadamente rara, los paquetes comprometidos portan atestaciones de procedencia SLSA Build Level 3 válidas, convirtiendo esto en el primer worm npm documentado que produce paquetes maliciosos con atestación válidamente emitida.
Avital Harel, líder de investigación en seguridad de Upwind, contextualizó bien la gravedad: esta campaña refleja un cambio más amplio en los ataques a la cadena de suministro, pasando del compromiso aislado de paquetes a una propagación orientada por identidad a través de infraestructura de CI/CD confiable. Una vez que los atacantes obtienen acceso a workflows de publicación e identidades de pipeline, el propio proceso de entrega de software se convierte en el mecanismo de distribución. El desafío para los defensores es que gran parte de esta actividad puede parecer legítima en la superficie, lo que hace que la visibilidad comportamental durante las instalaciones y builds sea cada vez más importante.
Lo que los desarrolladores necesitan saber ahora
Lo primero que cualquier desarrollador o equipo de ingeniería debe entender es que la procedencia válida ya no es sinónimo de seguridad absoluta. El hecho de que Mini Shai-Hulud haya logrado publicar paquetes con certificación SLSA Build Level 3 legítima obliga a la comunidad a revisar el peso que esa garantía tiene dentro de un proceso de evaluación de seguridad. Esto no significa abandonar el uso de frameworks como SLSA, que siguen siendo herramientas valiosas dentro de una estrategia más amplia. Significa que necesitan ser tratados como una capa de verificación entre varias, y no como un certificado definitivo de que un paquete es seguro para uso en producción.
Prácticas como auditoría frecuente de dependencias, uso de lockfiles actualizados y monitoreo activo de cambios en los paquetes utilizados son más importantes que nunca. Herramientas que alerten sobre publicaciones inesperadas de nuevas versiones, especialmente en paquetes ampliamente utilizados, pueden ser un diferencial importante para detectar actividades sospechosas antes de que se propaguen por el entorno.
Acciones prácticas para proteger tu entorno
- No revoques tokens npm inmediatamente si sospechas de un compromiso. Aísla y crea una imagen forense del sistema primero para evitar activar el dead-mans switch.
- Revisa las configuraciones de OIDC trusted publisher para garantizar que la confianza esté acotada a branches protegidas y archivos de workflow específicos, no al repositorio completo.
- Audita los secretos almacenados en pipelines de CI/CD e implementa el principio de mínimo privilegio para tokens de publicación.
- Monitorea publicaciones inesperadas en paquetes que mantienes o de los cuales dependes, especialmente versiones que aparecen fuera del ciclo normal de release.
- Implementa verificaciones comportamentales que analicen lo que los paquetes hacen en tiempo de ejecución, no solo lo que aparentan ser en el momento de la instalación.
- Verifica tus dependencias contra las listas de versiones comprometidas publicadas por las empresas de seguridad que analizaron la campaña.
Los compromisos de seguridad necesitan evolucionar junto con las amenazas. Campañas como la de Mini Shai-Hulud muestran que los atacantes están invirtiendo tiempo y conocimiento técnico para entender exactamente cómo funcionan los sistemas de confianza del ecosistema open source, y después explotar exactamente esos mecanismos. La respuesta de la comunidad no puede ser menos sofisticada que eso.
Como destacó el análisis de Socket, esta actividad más reciente muestra que la campaña continúa propagándose tanto en npm como en PyPI, con paquetes afectados que abarcan infraestructura de búsqueda, herramientas de IA, paquetes de desarrollo relacionados con aviación, automatización empresarial, herramientas de frontend y ecosistemas adyacentes a CI/CD.
La seguridad de la cadena de suministro de software se ha convertido, de una vez por todas, en una responsabilidad colectiva que exige atención continua y colaboración activa entre mantenedores, empresas y la comunidad de seguridad. El Mini Shai-Hulud no es simplemente otro incidente más en la lista creciente de ataques supply chain. Es un punto de inflexión que demuestra cómo la confianza automatizada, cuando es explotada por agentes sofisticados, puede transformarse en la mayor vulnerabilidad de todo el ecosistema. 🛡️
