Contexto técnico
Me sumergí en el post-mortem de TanStack justo después de su publicación porque no es simplemente otro incidente de npm. Es peor: los paquetes maliciosos se liberaron a través del pipeline de lanzamiento oficial, lo que significa que cualquier equipo que construya integraciones de IA o entornos de producción basados en la confianza de la procedencia (provenance) debería preocuparse.
La ventana de ataque fue breve: el 11 de mayo de 2026, de 19:20 a 19:26 UTC. En esos seis minutos, un atacante publicó 84 versiones maliciosas en 42 paquetes de @tanstack/*.
No se robaron las contraseñas de los mantenedores. El flujo de trabajo de `npm publish` tampoco se vulneró directamente. El atacante manipuló las entradas en el CI de tal manera que el propio pipeline de TanStack lanzó las compilaciones infectadas utilizando su identidad OIDC de confianza.
Y aquí es donde realmente me detuve un minuto: los lanzamientos tenían atestaciones de procedencia válidas. Esto significa que la lógica habitual de "si tiene una firma y publicación confiable, debe estar limpio" falló por completo en este caso.
La cadena de ataque fue muy moderna. Primero, explotaron el peligroso patrón `pull_request_target`, el infame Pwn Request. Luego, envenenaron la caché de GitHub Actions en el límite entre el fork y el repositorio base. Finalmente, en el trabajo de lanzamiento, extrajeron el token OIDC de corta duración directamente de la memoria del proceso del runner.
En esencia, el CI se robó el token a sí mismo en el momento de la publicación. Esto ya no es una historia sobre "no guardes secretos en el repositorio". Es una historia sobre cómo las cachés, los artefactos y los límites de confianza (trust boundary) en GitHub Actions deben considerarse hostiles por defecto.
Si descargaste @tanstack/* durante estas fechas, no me limitaría a actualizar la versión. Reconstruiría el proyecto con un `lockfile` limpio, borraría la caché, revisaría los registros del CI en busca de solicitudes de red extrañas y rotaría cualquier secreto si el paquete infectado se ejecutó alguna vez en el pipeline.
¿Qué cambia esto para el negocio y la automatización?
Los equipos cuyos lanzamientos se basan en "bueno, tenemos publicación confiable" son los perdedores aquí. Los ganadores son aquellos que separan los PR no confiables, las compilaciones y las publicaciones en diferentes zonas de confianza.
La segunda lección es aún más práctica: la seguridad de la cadena de suministro ya no puede gestionarse manualmente con una lista de verificación trimestral. Se necesitan políticas sólidas, escaneo de `lockfile`, control de caché, respuesta a incidentes y reversiones automatizadas.
En Nahornyi AI Lab, abordamos precisamente estos problemas en la práctica: diseñamos una arquitectura de soluciones de IA en torno a los procesos de DevSecOps para que los equipos no descubran una vulneración a posteriori a través de los registros. Si tu CI/CD ya es complejo y nadie puede demostrar rápidamente qué es seguro, analicémoslo y construyamos una automatización de IA adaptada a tu flujo de trabajo real, no solo para un bonito diagrama en Notion.