Grafana Labs says the unauthorized access to its GitHub repositories, disclosed earlier in May, was tied to the TanStack supply chain attack. The company says attackers downloaded its codebase and accessed repositories containing internal operational and business information.
Grafana’s current position is also clear on the boundary: it says customer production systems and the Grafana Cloud platform were not affected. It also says the downloaded codebase was not modified, and that customers and open source users do not need to take action based on the incident as currently understood.
That distinction matters. This was still a serious source-code and internal-data exposure. But according to the company, it was not a production-platform compromise.
What Grafana says happened#
SecurityWeek reports that Grafana connected the GitHub repository access to the TanStack supply chain attack, a campaign that affected high-profile NPM and PyPI projects and deployed self-propagating information-stealing malware on victims’ computers.
Grafana says it detected malicious activity associated with the attack on May 11 and immediately rotated GitHub workflow tokens. That response did not fully close the window. One token was not revoked.
That missed token became the path in.
Grafana later reviewed the incident and found that a GitHub workflow it had initially considered unaffected had in fact been compromised. The company said: “A subsequent review confirmed that a specific GitHub workflow we originally deemed not impacted had, in fact, been compromised.”
On May 16, Grafana received a ransom demand from the attackers. The company says it refused to pay, started additional mitigation work, hardened its GitHub posture, and notified law enforcement.
What data was exposed#
Grafana says the current scope is limited to Grafana Labs GitHub repositories. That includes public and private source code, plus internal GitHub repositories.
The attackers downloaded Grafana’s codebase. They also accessed repositories that stored internal operational information and other business details.
Grafana says the exposed business data included contact names and email addresses that would be exchanged in a professional relationship context. The company emphasized that this was not information pulled from, or processed through, production systems or the Grafana Cloud platform.
That is an important technical and legal boundary. Source repositories often contain more than source code. They may include issue history, workflow configuration, internal notes, build logic, documentation drafts, operational references, and business metadata. Even when no production environment is touched, repository access can create downstream risk.
Attackers can use stolen code and internal context for several purposes:
- studying architecture and security assumptions;
- searching for secrets or weak workflow patterns;
- preparing more credible phishing or extortion attempts;
- finding issues that may not yet be public;
- mapping maintainers, vendors, and partner relationships.
Grafana has not said, based on the provided source material, that attackers found exploitable vulnerabilities, stole customer data, modified code, or accessed production systems. Those should not be inferred from the fact that repositories were downloaded.
What Grafana says was not affected#
Grafana says its production systems were not affected. It also says the Grafana Cloud platform was not affected.
The company says the downloaded codebase was not modified. That point is critical for open source users and customers, because modification would raise a different kind of supply-chain concern: whether malicious code had been inserted into releases, dependencies, or build paths.
According to Grafana, no action is needed from customers or open source users at this time.
That does not make the incident harmless. It means the known impact, as described by Grafana, sits in the repository and internal-information layer rather than the production-service layer.
For users, the difference is practical. If production systems and release artifacts were unaffected, the immediate response is usually monitoring and awareness, not emergency redeployment. If that assessment changes, the response would change with it.
Why one token can matter#
The useful lesson here is not “Grafana was breached.” It is narrower and more operational: a single unrevoked workflow token can preserve attacker access after a wider cleanup appears complete.
GitHub workflow tokens and CI/CD credentials sit close to the build and release process. They often have enough permission to read repositories, run automation, access artifacts, or interact with internal systems. Their exact power depends on configuration, scope, and surrounding controls.
In supply-chain incidents, token rotation is a standard response. But the hard part is inventory. Teams need to know which workflows exist, which tokens they use, what those tokens can access, where secrets are stored, and which jobs may have run under compromised conditions.
Grafana’s statement shows a common failure mode. The company rotated GitHub workflow tokens after detecting malicious activity, but one workflow was initially judged not impacted. That judgment later changed.
This is the uncomfortable part of supply-chain response: early scoping is often wrong. Not always because teams are careless, but because build systems are large, old workflows survive, permissions drift, and automation creates hidden trust paths.
What teams can check now#
Organizations using GitHub Actions, package registries, or similar CI/CD pipelines can treat this incident as a checklist prompt.
Start with workflow inventory. Identify every active and dormant workflow. Dormant automation can still carry permissions or secrets.
Review token scope. Default broad permissions are convenient until an incident. Prefer least privilege where possible. Read access, write access, package publishing rights, and environment deployment rights should not be bundled without need.
Rotate secrets after confirmed or suspected developer-machine compromise. Supply-chain malware that steals local credentials can cross the line from endpoint incident to repository incident quickly.
Check workflow run history. Look for unusual runs, unexpected branches, new artifacts, failed jobs with strange parameters, and changes to workflow files.
Separate source exposure from release compromise. Both matter, but they require different responses. Downloaded code is not the same as modified code. Modified release paths are more urgent for downstream users.
Finally, preserve evidence before cleanup where possible. Fast rotation helps containment. But incident response also needs logs, run metadata, access records, and artifact traces.
What not to overclaim#
The source material does not establish that Grafana Cloud was breached. It does not establish that customer production data was accessed. It does not establish that malicious code was inserted into Grafana’s codebase or releases. It also does not provide technical indicators, package names, attacker identity, or a full timeline beyond the dates reported.
The confirmed claim is still significant: Grafana attributes repository access to the TanStack supply chain attack, says one GitHub workflow token was not revoked, and says attackers downloaded code and accessed internal repository data before making a ransom demand.
That is enough to matter. It shows how a package ecosystem compromise can become a repository compromise through developer and workflow credentials. It also shows why incident response has to treat CI/CD state as part of the blast radius, not as background infrastructure.
For Grafana users, the current practical reading is measured: watch for further updates, but do not assume production compromise unless Grafana reports new findings. For security teams, the lesson is more direct. In a supply-chain incident, the token you miss may be the incident you still have.