Grafana Labs says attackers copied two private GitHub repositories after one workflow token was missed during credential rotation. The incident followed the TanStack npm supply-chain compromise and ended with a ransom demand, but Grafana says it found no evidence that source code was changed or that customer data was accessed.
The important part is the gap between “we rotated exposed secrets” and “every reachable automation credential is dead.” Grafana says it detected malicious activity related to the TanStack incident on May 11, rotated a significant number of GitHub workflow tokens, and later found that one workflow token had still been compromised [1].
What actually happened
According to Grafana’s own update, a later review showed that a GitHub workflow originally judged not impacted had in fact been compromised. On May 16, Grafana received a ransom demand intended to prevent publication of the copied codebase. The company says it chose not to pay, in line with FBI guidance that payment does not guarantee deletion or confidentiality.
That sequence is useful because it separates three different risks: the original npm supply-chain compromise, the credential rotation miss, and the later extortion attempt. Treating all three as one vague “breach” makes the remediation weaker. Each requires different evidence: package install logs, token inventory, GitHub audit logs, repository access history, and publishing history.
Why a missed workflow token matters
Workflow tokens are easy to underestimate because they are not always visible to application teams. They may sit inside CI/CD automation, helper workflows, release jobs, or repository maintenance tasks. After a package compromise, any token reachable from the runner should be considered suspect until proven otherwise.
- Map every GitHub Actions workflow that ran during the exposure window.
- Rotate tokens by capability, not only by the token name people remember.
- Review repository access logs for cloning, archive downloads, branch reads, and unusual workflow activity.
- Check whether copied code could expose additional secrets, internal endpoints, or deployment assumptions.
- Separate “source code copied” from “source code modified” during incident reporting.
What this changes for response teams
For developers and defenders, this is not only a Grafana story. After a supply-chain incident, token cleanup has to cover automation paths beyond the obvious package credential. The useful check is whether each remaining token can still reach private code.
Snyk’s analysis of the TanStack compromise described how malicious package activity can create downstream CI/CD risk beyond the package manager itself [2]. Grafana’s update shows the next step in that chain: a token that survives the first cleanup pass can turn a package incident into repository exposure days later.
Grafana’s statement also separates source-code copying from package tampering. That distinction matters: defenders should still review repository access logs, workflow runs, and package publishing history as different evidence streams. We covered the original TanStack package compromise in our Mini Shai-Hulud report, and a later GitHub-focused incident in our poisoned VS Code extension coverage.
References
- Grafana Labs, security update on the TanStack npm supply-chain ransomware incident, May 19, 2026. Update
- Snyk, analysis of compromised TanStack npm packages, May 2026. Analysis
Related Git hosting risk: after reviewing exposed repository tokens, admins should also check whether any self-hosted Gogs service is exposed to the unpatched Gogs RCE path.
