How a TanStack npm Compromise Got Grafana's GitHub Codebase Stolen

A Second Downstream Casualty of the TanStack Compromise in One Week

On May 16, 2026, Grafana Labs publicly confirmed that an unauthorized party gained access to its GitHub environment and downloaded source code from public and private repositories. The root cause, per Grafana's own writeup and independent reporting from Help Net Security and Cybersecurity Dive, traces back to the same TanStack npm supply-chain compromise that we covered last week when it reached a GitHub employee through a poisoned Nx Console extension.

This is the same upstream compromise reaching two different downstream targets through two different routes. Last week it was a malicious VS Code extension landing on a GitHub laptop. This week it is a leaked GitHub workflow token landing in an attacker's automation. Same root, different teeth.

What Grafana Says Happened

Grafana detected the malicious activity on May 11, 2026, and immediately started its incident response process. The team rotated a significant number of GitHub workflow tokens, but missed one. That single un-rotated token was enough for the attacker to access Grafana's GitHub environment and exfiltrate source code from both public and private repositories.

On May 16, Grafana issued a public statement. The May 18 update added the source-code-download confirmation and the attacker's ransom demand. By May 21 the wider security press had connected the root cause to the broader TanStack npm package compromise that has been rippling through developer ecosystems since early May.

Per Grafana's investigation:

• The breach scope is limited to the Grafana Labs GitHub environment, including public and private source code and internal GitHub repositories.
• There is no evidence that customer production systems or operations have been compromised.
• The Grafana Cloud platform itself is unaffected.
• No customer credentials or telemetry data were stored in the repositories the attackers accessed.

One Token Missed in the Rotation

The single technical detail that matters most for any team running CI: Grafana ran the rotation playbook, and a token still got through. This is not a story about Grafana being careless. It is a story about how token sprawl in a modern engineering organization can survive a coordinated rotation campaign.

GitHub workflow tokens, fine-grained PATs, deploy keys, app installation tokens, environment secrets, organization secrets, repository secrets, and gh CLI cached sessions all live in different places. A "rotate everything" exercise that does not have a programmatic inventory of every place an active GitHub credential is reachable will leave at least one behind. Grafana is one of the better-instrumented engineering teams on the open-source map, and they still missed one.

The Ransom

The attackers issued a ransom demand under threat of public data disclosure. Grafana declined to pay, citing the FBI's formal position that ransom payments do not guarantee data security and serve only to incentivize further criminal activity.

This aligns with the response pattern we are now seeing from organizations on the receiving end of TanStack and Shai-Hulud derivatives. GitHub itself, hit through the parallel Nx Console route, took the same posture: investigate, contain, communicate, do not pay. Healthier signal than the 2020-2022 era, where ransom payments were quietly common.

The TanStack Root and the Broader Campaign

Both the GitHub and Grafana breaches trace to the same upstream event: a compromised npm package in the TanStack family poisoned developer environments earlier this month, and the payload harvested credentials including GitHub CLI tokens, npm tokens, AWS keys, and SSH keys from developer machines.

From one upstream open-source compromise, the attackers branched into at least two distinct downstream attacks within two weeks:

• Through one Tanstack contributor who also had push access to nrwl/nx, into a poisoned Nx Console VS Code extension, into a GitHub employee's laptop, into roughly 3,800 GitHub-internal repositories. We covered the Nx Console chain in detail here.
• Through a Grafana developer whose GitHub workflow token was leaked, into Grafana's GitHub organization, into its source code.

Grafana has not publicly attributed the breach to TeamPCP or UNC6780 specifically, the threat actor responsible for the Nx Console route. The campaigns may share the upstream compromise without sharing the downstream operator. Either way, the lesson is the same: a single supply-chain event upstream can produce multiple, parallel, weeks-apart downstream incidents in completely different organizations.

What Was Taken, What Was Not

The attackers downloaded source code. They did not gain access to:

• Grafana Cloud customer environments
• Grafana Cloud telemetry data
• Customer credentials stored anywhere outside the source repositories
• Grafana's production systems

Source code disclosure is bad on its own. It hands attackers a head start on finding application-level vulnerabilities, embedded credential mistakes, and architectural assumptions worth attacking. But it is bounded. Grafana has the option to rotate any secrets that were ever committed to a repository (and any sensible secret scanner would have flagged those long ago), notify customers if any embedded credentials would affect them, and audit the source for hardcoded values that could indirectly expose customer environments.

For customers, the practical impact today is small: monitor Grafana's official channels, do not consume third-party "leaked Grafana source" if it appears, and watch for any follow-up Grafana CVEs in the coming weeks as the company audits the disclosed code for previously-private vulnerability classes.

What To Do Today

For any team that runs CI with GitHub workflow tokens, PATs, or any form of long-lived automation credential:

1. Build a programmatic inventory. A "rotate everything" exercise without an inventory of where every active credential lives will miss tokens. gh auth status on developer machines, gh api /user/installations for app installations, organization secret listings, environment secret listings, deploy keys, fine-grained PAT lists.
2. Adopt OIDC trusted publishing where possible. GitHub Actions can now publish to npm, PyPI, and many other registries without long-lived secrets. The new staged publishing flow on npm, shipped May 22, 2026, makes this even stronger by requiring a human 2FA approval on top of the OIDC publish.
3. Treat editor extension installs as code execution events. Nx Console, Cursor extensions, VS Code plugins, JetBrains plugins, all run with the developer's ambient credentials. Pin to known-good versions. Audit auto-update behavior. Treat the VS Code Marketplace and OpenVSX as low-trust by default.
4. Apply secret scanning everywhere, including private repos. If your private repos contain any committed credential, the next time your token leaks, those credentials are part of the attacker's loot. GitHub Advanced Security or open-source equivalents (gitleaks, trufflehog) on every push.
5. Rotate gh cached sessions on developer machines weekly. A gh token harvested from a developer home directory has a long useful life. Force-expire it. Some teams now require gh auth login on a 7-day cadence as policy.

Bottom Line

One upstream npm compromise. Two downstream organizational breaches in two weeks. The mechanic does not require a zero-day, an APT, or a phishing-resistant adversary. It requires one stale credential surviving one rotation pass.

The defensive shift is not better detection. It is fewer long-lived credentials, period. Every GitHub PAT and every workflow token you eliminate this quarter is one less line in the next rotation playbook, one less corner for a missed token to hide in. OIDC trusted publishing exists; secret-scanning exists; pinning extension versions exists. The work this quarter is migrating from "many credentials, careful rotation" to "few credentials, automated short lifetimes".

If your team is sitting on a large GitHub PAT surface, an active CI footprint that publishes to package registries, or an unreviewed editor extension policy across developer machines, our security and compliance work is exactly this audit. Token inventory, OIDC migration plan, extension policy, and a rotation runbook you can actually run cleanly under pressure.