The Grafana Breach Explained

STARTUP BREACHES

In mid-May 2026, Grafana Labs disclosed that an unauthorized party had downloaded code from five private Grafana repositories. The attacker did not exploit a vulnerability in Grafana’s product. They did not phish an employee. They did not compromise a production server.

They opened a pull request.

A single malicious pull request to a Grafana repository was enough to extract a privileged GitHub token, walk into the codebase, and walk back out with the keys to four more private repositories.

The CoinbaseCartel data-extortion crew, assessed by Halcyon and Fortinet FortiGuard Labs as an offshoot of the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems, claimed responsibility and demanded a ransom. Grafana refused to pay, citing FBI guidance. The codebase has not surfaced publicly at time of writing.

What is worth understanding is not the extortion attempt. What is worth understanding is how a misconfigured CI/CD pipeline became the breach surface, and why thousands of other repositories on GitHub are sitting on the same class of vulnerability right now.

The vulnerability class that opened the door

Public reporting on the May 2026 incident points to a misconfigured pull_request_target workflow, a class of GitHub Actions vulnerability called a Pwn Request. Grafana has not yet published a full post-incident review for this breach, so the specific second-stage technique is still emerging. What the security community has published describes the broader attack class, and that is what every engineering team needs to understand.

Pwn Request explained

A Pwn Request is a GitHub Actions misconfiguration where a workflow triggered by an external pull request runs with repository-level permissions and full access to secrets. It happens when a workflow uses the pull_request_target trigger instead of the safer pull_request trigger.

The distinction matters. A pull_request workflow runs in the contributor’s limited security context with no access to secrets. A pull_request_target workflow runs in the base repository’s privileged context with secrets injected into the environment. It was designed for narrow use cases like commenting on PRs or labelling them by file path. Misused, it becomes a remote code execution surface for anyone who can open a pull request.

The common second stage: script injection

Pwn Request alone gives a workflow secrets in scope. It does not by itself execute attacker code. The second stage in most documented Pwn Request exploits is a script injection: an inline shell or JavaScript statement inside the workflow that interpolates attacker-controlled values without proper sanitisation. The attacker-controlled values are mundane: branch names, pull request titles, issue comments. None of them feel like an attack surface. All of them are.

By slipping characters that break out of the intended literal context, back-ticks, $() command substitution, unescaped quotes, an external contributor can smuggle arbitrary commands into the CI runner. If those commands run in a workflow that already has secrets in scope, the runner becomes a remote shell with full access to whatever the workflow can touch. Whether Grafana’s May 2026 incident used this exact second stage is not yet public, but it is the pattern the broader Pwn Request class has produced repeatedly.

The exploit chain, step by step

Reconstructed from Grafana’s public statements and the coverage from security publications. Some details, particularly the exact exfiltration channel, have not yet been published.

1

Initial access via malicious pull request
The attacker forked a Grafana repository and opened a pull request that triggered the vulnerable workflow. A curl command pulled a malicious payload onto the runner. The privileged GitHub App token, injected into the environment by the pull_request_target trigger, was now within the attacker’s reach.

2

Token exfiltration with an encrypted payload
The payload dumped environment variables, including the GitHub App credentials available in the workflow, into a file. Cyber Security News reports the file was encrypted with a private key embedded in the malicious payload before exfiltration. This pattern keeps the stolen data unreadable to anyone monitoring runner network activity in real time. The exact exfiltration channel for the May 2026 incident has not been published.

3

Fork deletion to cover tracks
After the secrets were exfiltrated, the attacker deleted the fork that hosted the malicious pull request. The CI run logs remained in Grafana’s environment, but the originating repository was gone. For a security team scanning for suspicious pull request activity, the breadcrumb trail had just been swept.

4

Lateral movement across repositories
The stolen token had access well beyond the original repository. The attacker used it to download code from four additional private Grafana repositories. The blast radius from one misconfigured workflow had expanded across a meaningful portion of the engineering organisation. Grafana’s investigation later confirmed the stolen artefact was the source code itself. The attacker did not modify code, reach production systems, or access customer data.

5

A canary token fired
Grafana had thousands of canary tokens deployed across its environment as tripwires, a programme it had built out following its previous GitHub Actions incident. One of those tokens was triggered during the lateral movement and alerted the security team. Threat intelligence from Mandiant suggests the average gap between credential theft and active exploitation is around eleven days. Grafana caught it inside that window. The prevention layer had already failed. The detection layer is what bounded the damage.

The extortion attempt and Grafana’s refusal

CoinbaseCartel emerged in September 2025 and has claimed roughly 170 victims across healthcare, technology, transportation, manufacturing, and business services. Unlike traditional ransomware groups, they do not encrypt systems. Their leverage is the threat of public release. Steal the data, demand payment, publish if refused.

Grafana refused. The company cited FBI guidance that paying ransoms offers no recovery guarantee and only incentivises more attacks.

That is the right call, and a harder one than it sounds when the leverage is your codebase. Days earlier, the educational technology company Instructure had settled with ShinyHunters after a similar threat aimed at terabytes of data belonging to thousands of US schools and universities. Two extortion demands. Two different decisions. The market is watching which approach holds up over the next twelve months.

Why this matters beyond Grafana

The Pwn Request vulnerability is not exotic. Independent security researchers at Orca Security have demonstrated working exploits against repositories owned by Microsoft, Google, and Nvidia using the same pattern, and have estimated that thousands of repositories remain at risk of exploitation. Many of those repositories belong to companies that have a SOC 2 report and an annual penetration test and consider themselves protected.

For an early-stage company, the implication is direct. CI/CD pipelines are not a developer convenience. They are a production attack surface with the same blast radius as your application servers. A workflow that runs unsanitised input from an external pull request is functionally equivalent to running unauthenticated code on your build machine, with whatever code security coverage that machine has.

Risky
pull_request_target with PR checkout

Runs in the base repository’s context with full access to secrets. Designed for narrow use cases like commenting on PRs. Dangerous if the workflow then checks out and executes PR code or interpolates PR metadata.

Safer
pull_request

Runs in the PR author’s limited security context with no access to repository secrets. Sufficient for almost all CI workflows: lint, test, build verification. Safe by default.

The fix is not complicated. Audit existing GitHub Actions workflows for pull_request_target usage. Replace with pull_request wherever the workflow does not specifically need privileged context. Where privileged context is required, never check out or interpolate PR-controlled input from the privileged workflow. Pin Actions to specific commit SHAs rather than tags. Protect production secrets behind GitHub Environments with required approvals. Rotate any high-value secrets every 90 days regardless of incident history.

What every engineering team should do this week

For early-stage companies, the actions are straightforward and inexpensive. None of them require a dedicated security team.

  • ✓
    Audit GitHub Actions workflows for pull_request_target usage. Open-source tools like Gato-X (by Adnan Khan, which Grafana sponsors) and Zizmor (by William Woodruff) can identify vulnerable workflow patterns in minutes.
  • ✓
    Restrict CI secrets to least-privilege scopes. A GitHub App token should not have access to four other repositories. Scope tokens to the minimum repository set their workflow legitimately needs. Review every permission individually.
  • ✓
    Move production secrets to GitHub Environments with mandatory reviewers. Environment-scoped secrets require explicit approval before a workflow can access them. Even if a CI workflow is compromised, the deploy secrets stay behind a gate.
  • ✓
    Deploy canary tokens. Free options exist. Plant them across high-value repositories, cloud accounts, and admin panels. The point is detection when prevention fails, and Grafana’s experience shows the difference between a contained incident and an undetected one is measured in days.
  • ✓
    Use OIDC federation for cloud deployments. Replace static AWS keys, Docker Hub credentials, and npm publish tokens with short-lived OIDC credentials. Even if a workflow is compromised, OIDC tokens expire before the attacker can use them at scale.
  • ✓
    Require approval for first-time contributor workflows. GitHub allows repository owners to require manual approval before a new contributor’s workflow can run. One toggle. Free. Defends against drive-by Pwn Request attacks like the one that hit Grafana.

None of this is novel. All of it has been recommended for years. The Grafana breach matters because it is the latest reminder that recommendations and reality drift apart fast when engineering teams are shipping product under time pressure. Supply chain attacks against developer infrastructure are not slowing down. They are becoming the dominant pattern.

If the company building Grafana can be hit this way, the question for every founder is straightforward: when was the last time someone audited your GitHub Actions workflows?

CI/CD pipelines are now a production attack surface. Treat them that way.

Osto’s SAST and Code Security modules scan your repositories continuously for the kind of workflow misconfigurations that took Grafana’s codebase. One platform for source code security, cloud posture, and the entire stack underneath. If your engineering team is shipping faster than your security can keep up, we should talk.

Talk to us at Osto

The Hacker News coverage ·
Cyber Security News technical breakdown ·
Cyber Kendra incident analysis