Grafana atribuye el acceso a repositorios privados a un token de GitHub Actions que no se rotó tras el ataque a TanStack

Hispasec

hace 2 horas

Grafana confirmó un acceso no autorizado a repositorios privados tras quedarse sin rotar un token de GitHub Actions expuesto durante el ataque de cadena de suministro a TanStack en npm. Se descargaron código fuente e información operativa y de contactos, sin señales de cambios en el código ni impacto en entornos de producción de clientes o en Grafana Cloud.

Más allá del malware en dependencias, este incidente muestra cómo un fallo de higiene en CI/CD puede convertir una intrusión limitada en un problema mayor: basta con que una sola credencial quede fuera del proceso de contención para reabrir la puerta. En el caso de Grafana Labs, el vector inicial se relaciona con el compromiso de la cadena de suministro de TanStack en npm, que llevó a la exposición de credenciales dentro de su entorno de GitHub Actions.

El ataque a TanStack se concentró en una ventana muy corta, el 11 de mayo de 2026 entre las 19:20 y las 19:26 UTC, y consistió en la publicación de decenas de versiones maliciosas, 84 en total, repartidas en 42 paquetes @tanstack/. La campaña abusó de OIDC Trusted Publishing de GitHub Actions, lo que permitió publicar en el registro con un token OIDC obtenido durante un workflow, sin depender de tokens de npm de larga duración. A nivel técnico, se ha descrito una cadena que combina un workflow con pull_request_target, un patrón conocido como Pwn Request, junto con cache poisoning en las cachés de GitHub Actions* entre forks y el repositorio base, y la extracción de secretos desde la memoria del runner.

Dentro de esos paquetes, los manifiestos incluían una optionalDependency que apuntaba a un commit huérfano en GitHub, usando el nombre ficticio @tanstack/setup y la referencia github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c. La carga útil, identificada como router_init.js y con un tamaño aproximado de 2,3 MB, se ejecutaba durante la instalación a través de scripts del ecosistema npm, y realizaba robo de credenciales. La exfiltración se apoyaba en infraestructura asociada a Session, destacando filev2.getsession.org y varios seed*.getsession.org, con comunicaciones cifradas de extremo a extremo. Además, se observaron comportamientos de propagación tipo gusano, ya que el malware enumeraba paquetes mantenidos por la víctima y republicaba versiones comprometidas, maximizando el alcance dentro del ecosistema.

En Grafana, esa fase inicial permitió que se filtraran tokens de workflows. La compañía detectó actividad maliciosa el 1 de mayo y rotó numerosos tokens de GitHub Actions como parte de la respuesta. Sin embargo, una credencial concreta quedó fuera del proceso de rotación, y ese token ‘rezagado’ se utilizó después para acceder a repositorios privados. El resultado confirmado fue la descarga de código fuente, además de información operativa y datos de contactos comerciales, como nombres y correos empleados en relaciones profesionales.

En paralelo, la actividad maliciosa vinculada a TanStack se detectó el 11 de mayo de 2026 y la extorsión a Grafana se recibió el 16 de mayo de 2026. La organización notificó a autoridades federales y optó por no pagar, en línea con la recomendación del FBI de no negociar pagos. En cuanto al impacto, el alcance confirmado se limita al entorno de GitHub de la compañía, sin evidencias de compromiso de Grafana Cloud ni de sistemas de producción u operaciones de clientes. También se indicó que no se modificó el código durante el incidente, por lo que el código descargado por usuarios en ese periodo se considera seguro.

Para equipos que operan pipelines similares, la lección principal es operativa: tras cualquier indicio de exfiltración, hay que inventariar y rotar de forma completa todas las credenciales usadas en CI/CD, sin excluir workflows por una clasificación errónea. Es clave revisar jobs que consumieron dependencias potencialmente afectadas y qué secretos estuvieron disponibles en ejecución, aplicar mínimo privilegio al GITHUB_TOKEN y a los permisos de workflows, y reforzar la observabilidad con alertas por autenticaciones inusuales, clones o descargas masivas de repositorios privados.

En defensa de la cadena de suministro, conviene endurecer el consumo de dependencias con pinning de versiones, controles de integridad y revisiones antes de ejecutar en CI. En momentos de alto riesgo, se puede recurrir temporalmente a instalaciones más estrictas, como npm ci o pnpm con frozen lockfile, e incluso usar ignore scripts como control defensivo mientras se valida la integridad. Si existe sospecha de cache poisoning, es recomendable purgar y rotar cachés de GitHub Actions y de gestores de paquetes, incluido el almacén de pnpm, antes de reanudar publicaciones.

También se han descrito mecanismos de persistencia fuera de node_modules, con artefactos en directorios .vscode y .claude, que pueden sobrevivir a un borrado de dependencias. Se documentó un componente destructivo, gh-token-monitor, con persistencia en macOS mediante LaunchAgents y en Linux mediante systemd de usuario, capaz de borrar el directorio home si detecta revocación del token. Por ello, antes de revocar tokens potencialmente expuestos, conviene buscar y eliminar persistencia para reducir el riesgo de acciones destructivas.

Como verificación concreta, se recomienda buscar en lockfiles y artefactos de build la huella @tanstack/setup con la referencia github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c y tratar cualquier coincidencia como incidente. Otra práctica útil es validar versiones sin ejecutar scripts, por ejemplo descargando el tarball con npm pack para revisar el package.json y detectar la presencia de router_init.js. En paralelo, bloquear y monitorizar tráfico saliente hacia filev2.getsession.org y seed*.getsession.org, además de cualquier IOC confirmado, ayuda a cortar la exfiltración.

Por último, si se utiliza OIDC Trusted Publishing para npm, merece la pena limitar su alcance a un workflow concreto y a una rama protegida, evitando confianza a nivel de repositorio cuando sea posible. Y, de forma crítica, incorporar un paso de verificación post incidente que confirme con evidencias que la rotación de todos los tokens y secretos se completó de verdad, para que no vuelva a ocurrir lo que aquí desencadenó el acceso a repositorios privados: un solo token olvidado.