La seguridad de la cadena de suministro de software acaba de recibir otro aviso serio. El grupo TeamPCP, según el análisis de StepSecurity, ha lanzado una nueva oleada de Mini Shai-Hulud, un gusano capaz de comprometer paquetes legítimos de npm y propagarse a otros proyectos usando credenciales robadas dentro de entornos CI/CD. Esta vez el incidente ha golpeado de lleno al ecosistema de TanStack, con 84 versiones maliciosas publicadas en 42 paquetes @tanstack/* el 11 de mayo de 2026 entre las 19:20 y las 19:26 UTC. TanStack ha confirmado el incidente en su propio postmortem.
La gravedad del caso no está solo en el número de paquetes afectados. Lo más delicado es que las versiones maliciosas fueron publicadas a través de la propia canalización legítima de GitHub Actions del proyecto, con identidad OIDC de confianza y con atestaciones de procedencia SLSA válidas. Dicho de otra forma: desde fuera, los paquetes podían parecer publicados por un flujo moderno y bien protegido. El problema es que el atacante consiguió que ese flujo trabajara para él.
Cuando la procedencia válida no significa paquete seguro
Durante los últimos años, buena parte de la industria ha empujado hacia prácticas como 2FA, trusted publishing, OIDC y SLSA para reducir el riesgo de robo de tokens y publicación fraudulenta en registros como npm. Son avances necesarios, pero el caso de TanStack muestra una limitación incómoda: una atestación de procedencia demuestra qué canalización construyó o publicó un artefacto, pero no garantiza que esa canalización no haya sido manipulada durante la ejecución.
TanStack explica que el atacante encadenó varias técnicas: el patrón conocido como pull_request_target Pwn Request, envenenamiento de caché de GitHub Actions entre fork y repositorio base, y extracción en tiempo de ejecución de un token OIDC desde la memoria del runner. La organización recalca que no se robaron tokens npm y que el flujo de publicación de npm no fue comprometido como tal. La publicación salió por una vía legítima, pero tras un abuso de la propia infraestructura de automatización.
StepSecurity sostiene que Mini Shai-Hulud funciona como un gusano real. Una vez consigue secretos de una canalización, enumera los paquetes que el mantenedor puede publicar e intenta infectar nuevas versiones. La campaña no se habría limitado a TanStack: análisis de StepSecurity, Snyk, The Hacker News y otros equipos de seguridad señalan impactos o intentos de propagación hacia paquetes de Mistral AI, UiPath, DraftLab, Squawk y otros mantenedores.
La lista de paquetes afectados es amplia y sigue siendo revisada por distintos equipos. En el caso de TanStack, el compromiso incluyó paquetes asociados a Router, Start, adaptadores y herramientas para React, Solid y Vue. Snyk señala que @tanstack/react-router, uno de los paquetes afectados, supera por sí solo los 12 millones de descargas semanales, lo que ayuda a entender el posible alcance de exposición, aunque descarga no equivale automáticamente a ejecución maliciosa en todos los entornos.
| Dato del incidente | Información confirmada o reportada |
|---|---|
| Fecha principal del compromiso de TanStack | 11/05/2026 |
| Ventana de publicación maliciosa | 19:20-19:26 UTC |
Paquetes @tanstack/* afectados | 42 |
| Versiones maliciosas en TanStack | 84 |
| Técnica clave | Abuso de GitHub Actions, caché y OIDC |
| Señal especialmente preocupante | Paquetes maliciosos con procedencia SLSA válida |
| Otros ecosistemas citados | Mistral AI, UiPath, DraftLab, Squawk y otros |
Un robo de secretos orientado a desarrolladores y pipelines
El objetivo del malware no era solo comprometer una librería concreta. Según StepSecurity, el payload buscaba credenciales en entornos de desarrollo y CI/CD: tokens de GitHub, npm, claves cloud, secretos de Kubernetes, Vault, SSH y otros ficheros habituales en máquinas de desarrolladores o runners. El análisis también describe técnicas de persistencia en herramientas de desarrollo y exfiltración cifrada mediante varios canales.
Este punto es importante para los equipos de seguridad porque cambia la respuesta al incidente. No basta con actualizar el paquete o borrar node_modules. Si una versión comprometida llegó a ejecutarse en una máquina de desarrollo o en una pipeline con secretos accesibles, hay que asumir exposición de credenciales. Eso implica rotación de tokens, revisión de logs, búsqueda de publicaciones sospechosas y auditoría de workflows modificados.
Los indicadores publicados por StepSecurity incluyen la presencia de un fichero malicioso en la raíz del paquete, dependencias opcionales apuntando a un commit concreto en GitHub, anomalías de tamaño en los tarballs y conexiones salientes a dominios de control. TanStack, por su parte, ha trabajado en deprecar versiones afectadas, coordinar con npm y reforzar su configuración de CI/CD tras el incidente.
El caso también deja una lectura incómoda sobre la automatización moderna. Muchas organizaciones han mejorado sus defensas eliminando tokens estáticos y usando identidades efímeras mediante OIDC. El problema aparece cuando el atacante consigue ejecutar código dentro del contexto adecuado. En ese escenario, no necesita robar una contraseña permanente: puede pedir credenciales temporales válidas desde el propio runner y usarlas antes de que expiren.
Qué deberían revisar los equipos técnicos
La primera comprobación es el árbol de dependencias. Los equipos que usen paquetes de TanStack, UiPath, Mistral, DraftLab, Squawk u otros nombres citados en los análisis deberían revisar sus lockfiles, comprobar versiones instaladas y contrastarlas con las listas actualizadas de StepSecurity, TanStack y otros proveedores de seguridad. Si aparece una versión comprometida, lo prudente es reconstruir desde una versión limpia y no limitarse a reinstalar encima.
La segunda revisión está en CI/CD. Hay que analizar ejecuciones de GitHub Actions durante la ventana del incidente y en las horas posteriores, buscar conexiones salientes anómalas, publicaciones npm no previstas, ramas sospechosas, workflows nuevos o modificados y artefactos que no deberían existir. En entornos donde se instalaron paquetes comprometidos, todos los secretos accesibles al runner deben considerarse comprometidos hasta demostrar lo contrario.
La tercera medida es estructural. Los equipos deberían revisar el uso de pull_request_target, separar con más dureza flujos de contribuciones externas y flujos con secretos, limitar permisos por defecto en GitHub Actions, conceder id-token: write solo cuando sea imprescindible, bloquear tráfico saliente no necesario desde runners y aplicar ventanas de enfriamiento para paquetes recién publicados. Este último punto puede resultar incómodo para equipos que viven al ritmo de actualizaciones automáticas, pero incidentes como este muestran por qué unas horas de espera pueden evitar un problema mayor.
También conviene ajustar el mensaje interno. SLSA, OIDC, 2FA y trusted publishing no han dejado de ser útiles. Al contrario, siguen reduciendo muchos riesgos. Lo que Mini Shai-Hulud demuestra es que no son una barrera mágica. Si el pipeline ejecuta código no confiable en un contexto con permisos de publicación, la firma y la procedencia pueden certificar con mucha precisión la ruta por la que entró el problema.
Para los mantenedores open source, el golpe es especialmente duro. Muchos proyectos populares funcionan con pocos recursos, alta presión de usuarios y automatizaciones complejas. Pedirles el mismo nivel de defensa que a una gran empresa no siempre es realista, pero el impacto de sus paquetes sí es empresarial. Esa tensión es una de las grandes asignaturas pendientes del ecosistema npm y, por extensión, de toda la cadena de suministro de software.
Mini Shai-Hulud no es solo otro malware escondido en npm. Es una prueba de estrés para la confianza en las canalizaciones modernas de publicación. El ataque muestra que la seguridad del software ya no puede quedarse en revisar el código fuente o verificar quién firma un paquete. También hay que entender qué ocurre dentro de la fábrica que lo construye.
Preguntas frecuentes
¿Qué es Mini Shai-Hulud?
Mini Shai-Hulud es un gusano de cadena de suministro que compromete paquetes npm, roba secretos de entornos de desarrollo o CI/CD e intenta propagarse publicando nuevas versiones maliciosas de paquetes mantenidos por las credenciales expuestas.
¿Qué paquetes de TanStack se vieron afectados?
TanStack confirmó 84 versiones maliciosas distribuidas en 42 paquetes @tanstack/*, publicadas el 11 de mayo de 2026. La lista completa debe consultarse en las actualizaciones oficiales de TanStack y StepSecurity, porque el inventario de paquetes afectados ha ido cambiando.
¿Por qué es tan grave que hubiera procedencia SLSA válida?
Porque demuestra que la procedencia criptográfica puede indicar que un paquete salió de una pipeline legítima, pero no que esa pipeline estuviera libre de manipulación. En este caso, el atacante abusó del flujo de CI/CD para publicar paquetes maliciosos con apariencia confiable.
¿Qué debe hacer una empresa si instaló una versión comprometida?
Debe asumir posible exposición de secretos, aislar los entornos afectados, revisar lockfiles, eliminar versiones comprometidas, rotar credenciales de GitHub, npm, cloud, SSH y CI/CD, auditar logs y comprobar si hubo publicaciones o cambios no autorizados en repositorios.
