Grafana GitHub Breach Tied to TanStack npm Supply Chain Attack

Grafana Labs has confirmed that attackers gained unauthorized access to its GitHub environment after the TanStack npm supply chain attack exposed parts of its development workflow. The attackers downloaded code and internal GitHub repository data, then issued a ransom demand under threat of disclosure.

The company said the incident was limited to its GitHub repositories. Grafana Cloud, production systems, customer environments, and customer operations were not impacted, based on the investigation so far.

Grafana also said its codebase was downloaded but not altered. Customers and open-source users do not need to take action at this time, although the company continues to review logs, telemetry, and repository activity.

What happened at Grafana?

Grafana traced the breach to the TanStack npm supply chain attack, part of the broader Mini Shai-Hulud campaign. Grafana detected malicious activity on May 11 and started its incident response process immediately.

The company rotated many GitHub workflow tokens during the initial response. However, Grafana later found that one missed token allowed attackers to access GitHub repositories.

A follow-up review showed that a GitHub workflow first judged as unaffected had actually been compromised. That missed exposure became the path into the company’s GitHub environment.

Grafana breach at a glance

Detail	Information
Company affected	Grafana Labs
Initial activity detected	May 11, 2026
Attack confirmed	May 16, 2026
Linked campaign	TanStack npm supply chain attack and Mini Shai-Hulud
Environment affected	Grafana Labs GitHub repositories
Data accessed	Public and private source code, internal GitHub repositories, operational information, and business contact details
Customer impact	No evidence of impact to Grafana Cloud, production systems, customer operations, or customer environments

What data did attackers access?

Grafana said the downloaded content included public and private source code repositories. Attackers also accessed internal GitHub repositories used by some teams for collaboration and operational work.

The exposed internal data included business contact names and email addresses. Grafana said this information came from professional relationship contexts, not from Grafana Cloud or customer production systems.

The company has not reported evidence that attackers modified source code. That detail matters because a code alteration could create downstream risk for users, integrations, or future software builds.

Why the TanStack attack matters

The TanStack compromise shows how quickly a software supply chain incident can spread beyond the original project. TanStack said attackers published 84 malicious versions across 42 packages on May 11, 2026.

Those packages were part of the TanStack Router and Start ecosystem. According to TanStack, the malicious versions were deprecated within about an hour and later removed from npm.

The malicious packages were designed to run during installation and harvest credentials from developer machines and CI environments. That included cloud credentials, GitHub tokens, npm credentials, SSH keys, Kubernetes tokens, and other sensitive material.

How the breach unfolded

• Attackers compromised TanStack npm packages as part of Mini Shai-Hulud.
• Grafana detected malicious activity on May 11.
• Grafana rotated a large number of GitHub workflow tokens.
• One overlooked workflow token remained exposed.
• Attackers used the token to access Grafana’s GitHub repositories.
• Repository data was downloaded from the GitHub environment.
• Grafana received a ransom demand on May 16.
• The company refused to pay and notified federal law enforcement.

Grafana refused to pay the ransom

Grafana said the attackers demanded a ransom to prevent the release of the downloaded codebase. The company decided not to pay.

Grafana said that decision aligns with FBI guidance. The FBI discourages ransom payments because payment does not guarantee recovery, does not guarantee stolen data will stay private, and can encourage more attacks.

The incident therefore looks more like data theft and cyber extortion than a classic ransomware encryption event. Grafana has not said that attackers encrypted production systems or interrupted Grafana Cloud services.

What Grafana has done in response

Grafana said it launched mitigation steps after the ransom demand. The company rotated automation tokens, audited commits since the May 11 incident, improved monitoring, and started hardening its GitHub security posture.

The company also said it is strengthening its CI/CD pipelines to reduce the chance of a similar compromise. That work matters because modern build systems often hold access to source code, package registries, cloud services, and deployment workflows.

Federal law enforcement has been notified. Grafana said it will continue cooperating with authorities and will publish more information after its post-incident review is complete.

What customers need to know

Question	Current answer
Was Grafana Cloud affected?	Grafana says there is no evidence that Grafana Cloud was impacted.
Were customer production systems affected?	Grafana says there is no evidence that customer production systems or operations were compromised.
Was Grafana source code changed?	Grafana says the codebase was downloaded but not altered.
Do customers need to take action?	Grafana says no action is needed from customers or open-source users at this time.
Is the investigation finished?	No. Grafana says the investigation is ongoing.

Why CI/CD tokens are high-value targets

CI/CD tokens can give attackers a direct path into repositories, package publishing workflows, cloud resources, and automation systems. A single exposed token can matter more than a compromised password if it carries broad permissions.

In this case, Grafana said a missed GitHub workflow token allowed continued access after the first wave of remediation. That is a common challenge during supply chain incidents because organizations must quickly identify every secret exposed to infected developer machines and CI runners.

The risk grows when workflows have access to many repositories or when tokens stay valid longer than needed. Short-lived credentials, strict token scoping, and automated secret rotation can reduce the blast radius.

How developers should respond to TanStack-related exposure

TanStack said every currently available published version of every TanStack package is safe to install. However, it also warned that anyone who installed affected versions on May 11 should treat that install host as potentially compromised.

Developers and security teams should check whether any affected TanStack versions were installed in local environments, CI runners, build servers, or automated dependency update jobs.

If exposure is possible, teams should rotate reachable credentials rather than trying to guess which secrets were accessed. That includes GitHub tokens, npm tokens, SSH keys, cloud keys, Kubernetes credentials, Vault tokens, and other secrets present on the host.

Recommended security steps

• Review package installation logs for affected TanStack versions on May 11.
• Rotate credentials that were reachable from developer machines or CI runners.
• Audit GitHub Actions workflows for unnecessary token permissions.
• Scope workflow tokens to the minimum repositories and actions needed.
• Use short-lived credentials where possible.
• Monitor for unexpected repository clones, workflow runs, and token usage.
• Set dependency update controls to reduce the risk of installing newly published malicious packages immediately.
• Review npm provenance and package source, but do not treat provenance alone as proof of safety.

Why provenance did not prevent the TanStack compromise

The TanStack incident is important because the compromised packages carried valid provenance signals. That means normal trust indicators did not fully protect downstream users.

TanStack said the attacker abused GitHub Actions behavior, cache poisoning, and a short-lived OIDC token to publish malicious package versions. The attack did not depend on stealing long-lived npm tokens.

This shows a broader problem for the open-source ecosystem. Security controls can fail when attackers compromise the trusted build process itself instead of attacking the final package directly.

The bigger supply chain lesson

The Grafana breach shows how a compromise in one open-source ecosystem can reach major software companies through build pipelines and developer tooling.

Attackers increasingly target package managers, CI workflows, browser extensions, IDE plugins, and automation tokens because these systems sit close to source code and credentials.

For organizations, the main lesson is clear. Dependency security, token hygiene, CI/CD hardening, and fast credential rotation must work together. A single missed automation token can keep an intrusion alive after the first cleanup effort.

FAQ