Grafana Labs has become the latest high-profile victim of source code theft — and one of the few companies this year to publicly tell their extortionists to get lost. The monitoring and observability giant disclosed on May 16, 2026, that an unauthorized party had used a stolen GitHub token to access and download its entire codebase. The group claiming responsibility is CoinbaseCartel, an extortion crew assessed by threat intelligence firms as an offshoot of the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems.

No customer data was accessed. Grafana said no. The codebase is still out there.

The Attack: CI/CD as a Weapon

The attack vector here is worth studying closely because it’s clever, increasingly common, and surprisingly hard to defend against at scale.

The attacker began with something entirely routine: they forked a public Grafana repository. Forking is a foundational open-source workflow; it raises no flags, requires no special access, and happens thousands of times a day across major projects. From that forked repository, they submitted a pull request containing a malicious curl command hidden within the code changes.

The critical piece is what happened next. Grafana’s CI/CD pipeline was configured with a pull_request_target GitHub Actions workflow — a workflow type specifically designed to run with elevated permissions even when triggered by pull requests from external forks. This is the documented footgun of the pull_request_target trigger: unlike the standard pull_request event, it runs in the context of the target repository, with access to secrets and environment variables, even when the triggering code comes from an untrusted fork.

When the workflow executed, it ran the attacker’s injected curl command inside Grafana’s trusted CI environment. That command dumped environment variables from the runner — including a privileged GitHub token with broad repository access. With that token in hand, the attacker was authenticated to Grafana’s GitHub organization and proceeded to download the codebase.

Grafana disclosed the breach in a six-part thread on X on May 16, describing the attack chain in detail and confirming that “an unauthorized party obtained a token that granted them the ability to access the company’s GitHub environment and download its codebase.”

CoinbaseCartel: A New Name, Familiar DNA

CoinbaseCartel is a relatively new entrant to the extortion landscape, having emerged in September 2025. Threat intelligence assessments link it to the extended ecosystem of ShinyHunters, Scattered Spider, and LAPSUS$ — three of the most prolific and disruptive cybercrime organizations of the past several years.

The group’s modus operandi aligns closely with what the LAPSUS$/Scattered Spider constellation pioneered: target source code and internal intellectual property, skip the ransomware encryption step entirely, and use the threat of public exposure as leverage. It’s a cleaner, faster model — no deployment of malware payloads, no noisy encryption events triggering endpoint detection, just exfiltration and extortion.

Whether CoinbaseCartel operates as a true offshoot with shared tooling and membership, or simply adopts the same playbook through ideological alignment, remains under investigation. But the Grafana incident fits the pattern precisely: compromise a trusted internal system through a legitimate workflow, exfiltrate quietly, then demand payment under threat of publication.

Grafana’s Response: No

When the extortion demand landed, Grafana’s position was clear and publicly stated. The company refused to pay, citing long-standing FBI guidance that paying ransoms does not guarantee data destruction, does not guarantee that attackers won’t return, and actively incentivizes further attacks by demonstrating that the model works.

“Paying cybercriminals doesn’t guarantee you or your organization will get any data back,” Grafana stated, quoting FBI language directly. “It offers an incentive for others to get involved in this type of illegal activity.”

The refusal puts Grafana in a small club. The economic pressure on companies holding stolen source code is substantial — the prospect of proprietary code, internal tooling, and architectural secrets being published or sold is genuinely damaging. Most companies weigh that against the optics of paying, and many pay quietly. Grafana didn’t.

Whether CoinbaseCartel follows through on any publication threat remains to be seen. In some cases, groups move on when targets refuse; in others, they escalate through partial releases. Grafana has not indicated that the stolen code has been published as of this writing.

What Was Taken — and What Wasn’t

Grafana’s investigation determined that the breach was confined to its GitHub environment: public and private source code, internal repositories, and associated content. No customer data or personal information was accessed. No evidence of impact to customer systems or the Grafana Cloud platform was found.

That’s a meaningful distinction for a company whose software is embedded in the monitoring infrastructure of thousands of organizations worldwide. Grafana’s dashboards sit inside cloud platforms, financial systems, healthcare infrastructure, and government networks. A breach of customer data or production platform access would have been a materially different incident. Source code theft, while serious, is a different threat category.

The more relevant downstream risk is what an attacker with Grafana’s full codebase could do with it: identify undisclosed vulnerabilities, develop exploits for future use against Grafana deployments, or sell that access to others who would. Grafana has not indicated whether a security audit of the codebase for potentially exposed credentials or undisclosed bugs is underway — both are standard practice following incidents of this type.

The pull_request_target Problem

The attack vector Grafana fell victim to is not new. GitHub itself has documented the risks of pull_request_target workflows running untrusted code, and the security community has flagged misconfigured CI pipelines as a persistent supply chain attack surface for years.

The challenge is that pull_request_target workflows serve legitimate purposes — many projects genuinely need them to run labeler bots, comment on PRs from external contributors, or access secrets during CI checks. The security risk comes when the workflow simultaneously runs untrusted code from the fork and has access to elevated secrets, which is exactly the combination GitHub warns against.

Grafana’s disclosure is a high-profile reminder that open-source projects — even those run by sophisticated engineering organizations — can have CI/CD misconfigurations that expose critical secrets to any attacker willing to submit a malicious pull request and wait.

What to Check If You Run GitHub Actions

  • Audit pull_request_target workflows — ensure they never execute code from the forking repository in a context that has access to secrets
  • Scope GitHub tokens to minimum required permissions — a token that can read all repositories should not also be able to be extracted via an environment variable dump
  • Use ephemeral, short-lived tokens where possible — a token that expires in minutes provides minimal value to an attacker who extracts it post-hoc
  • Review repository forks and recent pull requests against active CI workflows — anomalous curl or wget commands in PR diffs are a meaningful signal
  • Enable GitHub’s secret scanning and push protection — these won’t catch a token dumped from a runner, but they reduce the exposure surface for other credential leaks

Sources