Mini Shai-Hulud golpea Mistral AI y TanStack: paquetes de npm y PyPI robarían credenciales
Paquetes de Mistral AI y TanStack en npm y PyPI fueron ligados a malware para robar credenciales.
TL;DR:
Microsoft investiga el paquete mistralai==2.4.6 en PyPI tras detectar código malicioso que corría al importarse en Linux.Firmas de seguridad rastrean cientos de versiones maliciosas en npm y PyPI, con TanStack, Mistral AI, UiPath, OpenSearch y Guardrails AI entre los afectados.
El riesgo central no es solo el malware: es la posible exposición de tokens de GitHub, credenciales cloud, claves SSH y secretos de CI/CD.
Microsoft Threat Intelligence investiga el compromiso del paquete mistralai==2.4.6 en PyPI, mientras investigadores de seguridad lo conectan con la campaña Mini Shai-Hulud, una ola de ataques de cadena de suministro que también golpeó paquetes de TanStack y varios SDK de Mistral AI en npm. El incidente importa porque el malware no buscaba infectar usuarios finales: apuntaba a entornos de desarrollo, runners de CI/CD y máquinas Linux donde suelen vivir tokens de GitHub, credenciales cloud, llaves SSH y secretos de despliegue.
Mini Shai-Hulud es un malware de cadena de suministro diseñado para comprometer paquetes legítimos, robar credenciales de entornos de desarrollo y propagarse a otros proyectos mediante infraestructura confiable de publicación.
El caso de Mistral AI en PyPI es especialmente delicado porque el código malicioso no dependía de una instalación interactiva. Según el aviso de seguridad de Mistral, el paquete comprometido ejecutaba un script malicioso al momento de hacer import mistralai en Linux.
La versión afectada, mistralai==2.4.6, fue subida alrededor del 12 de mayo de 2026 a las 00:05 UTC y el proyecto quedó en cuarentena en PyPI. La página de PyPI muestra esa versión como “quarantined”, lo que impide instalarla mientras los administradores la revisan.
El código fue inyectado en src/mistralai/client/__init__.py. Desde ahí descargaba transformers.pyz desde 83.142.209.194, lo guardaba en /tmp/transformers.pyz y lo ejecutaba como proceso en segundo plano.
El nombre no parece casual. transformers.pyz imita visualmente a Hugging Face Transformers, una biblioteca muy usada en entornos de machine learning, lo que pudo ayudar a que el archivo pasara desapercibido en equipos de IA y desarrollo.
"Nuestra investigación actual indica que estuvo involucrado un dispositivo de desarrollo afectado. No tenemos indicios de que la infraestructura de Mistral haya sido comprometida."
Mistral también precisó que sus paquetes npm comprometidos ya fueron removidos por el registro y que, en su análisis, esos paquetes eran “inofensivos” porque setup.mjs hacía referencia a un archivo inexistente. Aun así, la compañía recomendó retirarlos si aparecen en lockfiles, caches, artefactos de build o imágenes de despliegue.
El golpe a TanStack expuso una falla incómoda: lo firmado también puede ser malicioso
El frente más amplio del ataque estuvo en npm. TanStack publicó un postmortem donde confirmó que, el 11 de mayo de 2026, entre 19:20 y 19:26 UTC, un atacante publicó 84 versiones maliciosas en 42 paquetes @tanstack/*.
La cadena técnica combinó tres elementos:
- Un workflow riesgoso con
pull_request_target. - Envenenamiento de cache en GitHub Actions.
- Extracción en memoria de un token OIDC del runner de GitHub Actions.
"No se robaron tokens de npm y el flujo de publicación de npm en sí no fue comprometido."
Ese matiz importa. El atacante no necesitó robar directamente un token permanente de npm. Según TanStack, el malware logró usar el pipeline legítimo para publicar paquetes con credenciales de corta vida generadas dentro del propio flujo de CI/CD.
El resultado fue más peligroso de lo normal: varios paquetes maliciosos llegaron con procedencia válida. Snyk y The Hacker News reportaron que esta ola incluyó paquetes con SLSA Build Level 3 provenance, una señal criptográfica pensada para confirmar que un paquete fue construido desde una fuente confiable.
La lección es brutal para equipos de seguridad: una firma válida no garantiza que el código sea seguro si el pipeline que firma ya fue manipulado.
Qué paquetes y credenciales estuvieron en la mira
Las cifras varían entre firmas porque la investigación sigue activa. Aikido reportó 373 entradas de versiones maliciosas en 169 nombres de paquetes npm. SafeDep elevó el alcance a más de 170 paquetes npm, 2 paquetes PyPI y 404 versiones maliciosas. BleepingComputer citó conteos de Endor Labs, Aikido y Socket que van de más de 160 paquetes npm a 416 artefactos comprometidos entre npm y PyPI.
Los paquetes señalados por investigadores incluyen:
@tanstack/react-router@tanstack/history@tanstack/router-core@mistralai/mistralai@mistralai/mistralai-azure@mistralai/mistralai-gcpmistralai==2.4.6en PyPIguardrails-ai==0.10.1en PyPI@opensearch-project/opensearch- Paquetes de
@uipath,@squawk,@tallyuiy otros scopes
El objetivo principal del payload era el robo de credenciales. Los reportes técnicos mencionan búsqueda de:
- Tokens de GitHub y GitHub Actions OIDC.
- Tokens de npm.
- Credenciales de AWS, GCP y metadata de instancias cloud.
- Tokens de Kubernetes service accounts.
- Tokens de HashiCorp Vault.
- Llaves SSH.
- Variables de entorno y archivos
.env. - Configuraciones de Claude Code y VS Code.
En el caso del paquete mistralai en PyPI, Microsoft también reportó lógica para evitar sistemas con configuración en ruso y una rama destructiva condicionada por geografía, con probabilidad de ejecutar rm -rf / cuando el sistema pareciera estar en Israel o Irán. Ese tipo de geofencing aparece en campañas criminales, pero no basta por sí solo para atribuir el ataque a un país o actor específico.
Qué deben revisar los equipos afectados
Mistral pidió dejar de usar las versiones afectadas, limpiar los sistemas donde se instalaron, rotar secretos y revisar logs cloud. Para Linux, los indicadores más directos son:
- Archivo
/tmp/transformers.pyz. - Proceso iniciado vía
python /tmp/transformers.pyz. - Variable de entorno
MISTRAL_INIT=1. - Conexiones salientes a
83.142.209.194.
También recomendó vigilar indicadores como api.masscan.cloud, filev2.getsession.org, git-tanstack.com, seed1.getsession.org y el host 83.142.209.194.
Para TanStack, cualquier equipo que haya instalado versiones afectadas el 11 de mayo de 2026 debe tratar el host como potencialmente comprometido. Eso aplica tanto a laptops de developers como a runners de CI/CD, imágenes de contenedor, caches privados y mirrors internos.
La respuesta recomendada no se queda en borrar el paquete. Hay que aislar el entorno, revisar persistencia, auditar actividad de publicación y rotar credenciales accesibles desde la máquina afectada.
El caso Mini Shai-Hulud muestra el nuevo campo de batalla: los atacantes ya no necesitan tocar producción directamente si pueden convertir los pipelines de desarrollo en su canal de distribución.
