Grafana Labs says hackers accessed GitHub repositories and downloaded codebase

Grafana Labs has confirmed that a cybercrime group accessed its GitHub repositories and downloaded company code after a token was missed during its response to the TanStack npm supply chain attack.

The company said the incident did not affect Grafana Cloud, customer production systems, or customer operations. Grafana also said the downloaded codebase was not altered, and customers and open-source users do not need to take action at this time.

The attack still matters because it shows how quickly a software supply chain compromise can spread from a third-party package into internal developer systems. In this case, Grafana says the breach remained limited to its GitHub environment, but the incident involved both public and private repositories.

What happened at Grafana Labs?

Grafana Labs said it detected malicious activity on May 11, 2026, after the TanStack npm supply chain attack affected developer environments. The company rotated a large number of GitHub workflow tokens during its initial response.

However, Grafana later found that one workflow it first believed was not affected had been compromised. A missed token then gave the attackers access to Grafana Labs GitHub repositories.

The attackers downloaded the company’s codebase and later sent a ransom demand on May 16. Grafana said it decided not to pay, citing the FBI’s position that paying a ransom does not guarantee safety and can encourage more criminal activity.

Detail	What Grafana confirmed
Incident type	Unauthorized access to GitHub repositories
Initial detection	May 11, 2026
Public confirmation	May 16, 2026
Root link	TanStack npm supply chain attack, also known as Mini Shai-Hulud
Data downloaded	Source code, internal GitHub repositories, and some internal business information
Customer impact	No evidence of compromised production systems or operations

What data was downloaded?

Grafana said the downloaded material included public and private source code, along with internal GitHub repositories used by some teams for collaboration and operational work.

The company also said those repositories included some business contact names and email addresses. Grafana described this as information exchanged in a professional relationship context, not data pulled from Grafana Cloud or customer production systems.

Grafana emphasized that its codebase was downloaded but not modified. It also said there is no evidence that customer systems, production systems, or customer operations were compromised.

Why the breach is linked to TanStack

The incident traces back to the wider TanStack npm supply chain attack, part of the Mini Shai-Hulud campaign. Security researchers have described the campaign as a developer-focused attack designed to steal secrets from build systems, CI/CD workflows, and software maintainers.

TanStack packages were compromised on May 11, allowing malicious package artifacts to spread through trusted development pipelines. Grafana said it detected activity that day and began rotating tokens, but one GitHub workflow token remained exposed.

This type of attack can look legitimate because malicious code may run inside trusted release or automation systems. That makes detection harder than with ordinary malware delivered through suspicious downloads or phishing attachments.

How Grafana responded

Grafana said it launched incident response efforts after detecting the malicious activity. Its response included rotating automation tokens, adding enhanced monitoring, auditing commits made since the May 11 incident, and hardening its GitHub security posture.

The company also notified federal law enforcement and said it will continue working with authorities as the investigation continues.

Grafana plans to publish a full post-incident report once its review is complete. For now, it says customers and users of its open-source projects do not need to make any changes.

• Grafana rotated automation tokens after the incident.
• The company added more monitoring around GitHub activity.
• It audited commits for signs of malicious changes.
• It said no customer production systems were compromised.
• It refused to pay the ransom demand.

Why GitHub workflow security remains a major risk

The breach highlights a broader issue across modern software development. Many companies rely on automated workflows that can access code, secrets, deployment systems, and cloud services.

If attackers reach those workflows, they may not need to break into production systems directly. They can instead target tokens, package publishing pipelines, and trusted automation paths.

GitHub has long advised developers to limit token permissions, protect secrets, review workflow changes, and avoid running untrusted code in privileged workflow contexts. These steps cannot remove all risk, but they reduce the blast radius when a dependency or workflow gets compromised.

What developers and companies should do now

Organizations that use GitHub Actions, npm packages, or open-source build pipelines should treat the Grafana incident as a reminder to review automation security before an attacker does it for them.

The most important step is to reduce trust in long-lived credentials and broad workflow permissions. Teams should also monitor workflow behavior, not just package names and version numbers.

For companies with large GitHub estates, manual reviews are not enough. Security teams need automated scanning, strict permission controls, and clear rules for how workflows handle pull requests, package installs, and deployment secrets.

• Rotate exposed or long-lived tokens after any suspected supply chain incident.
• Set GitHub workflow permissions to the minimum required access.
• Review workflows that run package installation or build steps from external contributions.
• Use code scanning and workflow security tools to detect risky patterns.
• Monitor for unusual repository cloning, token use, and workflow changes.
• Keep a clear incident response plan for developer infrastructure attacks.

FAQ