{"id":472,"date":"2026-05-18T05:40:43","date_gmt":"2026-05-18T05:40:43","guid":{"rendered":"https:\/\/www.osto.one\/resources\/?p=472"},"modified":"2026-05-18T16:41:20","modified_gmt":"2026-05-18T16:41:20","slug":"how-one-pull-request-stole-grafanas-entire-codebase","status":"publish","type":"post","link":"https:\/\/www.osto.one\/resources\/startup-breaches\/how-one-pull-request-stole-grafanas-entire-codebase\/","title":{"rendered":"The Grafana Breach Explained"},"content":{"rendered":"

<\/p>\n

In mid-May 2026, Grafana Labs<\/a> 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.<\/p>\n

They opened a pull request.<\/p>\n

<\/p>\n

\n

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.<\/p>\n<\/div>\n

The CoinbaseCartel data-extortion crew<\/a>, assessed by Halcyon and Fortinet FortiGuard Labs as an offshoot of the ShinyHunters<\/a>, 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.<\/p>\n

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.<\/p>\n

The vulnerability class that opened the door<\/h2>\n

Public reporting on the May 2026 incident points to a misconfigured pull_request_target<\/code> 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.<\/p>\n

<\/p>\n

\n
Pwn Request explained<\/div>\n

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<\/code> trigger instead of the safer pull_request<\/code> trigger.<\/p>\n

The distinction matters. A pull_request<\/code> workflow runs in the contributor’s limited security context with no access to secrets. A pull_request_target<\/code> 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.<\/p>\n<\/div>\n

<\/p>\n

\n
The common second stage: script injection<\/div>\n

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.<\/p>\n

By slipping characters that break out of the intended literal context, back-ticks, $()<\/code> 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.<\/p>\n<\/div>\n

The exploit chain, step by step<\/h2>\n

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

<\/p>\n

\n
\n 1<\/span><\/p>\n
\n
Initial access via malicious pull request<\/div>\n
The attacker forked a Grafana repository and opened a pull request that triggered the vulnerable workflow. A curl<\/code> command pulled a malicious payload onto the runner. The privileged GitHub App token, injected into the environment by the pull_request_target<\/code> trigger, was now within the attacker’s reach.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 2<\/span><\/p>\n
\n
Token exfiltration with an encrypted payload<\/div>\n
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.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 3<\/span><\/p>\n
\n
Fork deletion to cover tracks<\/div>\n
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.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 4<\/span><\/p>\n
\n
Lateral movement across repositories<\/div>\n
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.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n
\n 5<\/span><\/p>\n
\n
A canary token fired<\/div>\n
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.<\/div>\n<\/p><\/div>\n<\/p><\/div>\n<\/div>\n

The extortion attempt and Grafana’s refusal<\/h2>\n

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.<\/p>\n

Grafana refused. The company cited FBI guidance that paying ransoms offers no recovery guarantee and only incentivises more attacks.<\/p>\n

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.<\/p>\n

Why this matters beyond Grafana<\/h2>\n

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.<\/p>\n

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<\/a> coverage that machine has.<\/p>\n

<\/p>\n

\n
\n
Risky<\/div>\n
pull_request_target with PR checkout<\/div>\n

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.<\/p>\n<\/p><\/div>\n

\n
Safer<\/div>\n
pull_request<\/div>\n

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.<\/p>\n<\/p><\/div>\n<\/div>\n

The fix is not complicated. Audit existing GitHub Actions workflows for pull_request_target<\/code> usage. Replace with pull_request<\/code> 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.<\/p>\n

What every engineering team should do this week<\/h2>\n

For early-stage companies, the actions are straightforward and inexpensive. None of them require a dedicated security team.<\/p>\n