On May 16, 2026, Grafana Labs disclosed that an unauthorized party had downloaded its private codebase from GitHub. No customer data was accessed. The attacker demanded a ransom. Grafana refused. The incident was caught by a canary token that triggered within minutes of the breach.
The root cause was a single GitHub Actions workflow configured to run on pull_request_target with access to production secrets.
What is a Pwn Request?
The pull_request_target trigger was introduced by GitHub to give maintainers a safe way to run CI on pull requests from forks, because the fork normally runs in an isolated environment without repository secrets. The key word is "normally."
When a workflow uses pull_request_target and also checks out the pull request's code rather than the base branch, it runs forked, attacker-controlled code with repository-level secret access. This combination is the Pwn Request pattern.
It is not a vulnerability in GitHub. It is a documented behavior that is easy to configure accidentally and hard to spot in a workflow YAML file unless you are looking for it.
How the Grafana breach unfolded
A recently enabled GitHub Action at Grafana contained a Pwn Request configuration. The attacker forked a Grafana public repository and injected a malicious step that ran a curl command to dump the workflow's environment variables to a file. The output was encrypted with a private key before exfiltration. Submitting a pull request triggered the pull_request_target workflow, which ran the attacker's code with repository secret access. The attacker extracted a production GitHub token from the dump, used it to clone 4+ additional private repositories including Grafana's full codebase, then deleted the fork to erase evidence. A ransom demand followed.
Grafana detected the intrusion because one of its deployed canary tokens fired. The security team was alerted in real time, the compromised credentials were invalidated, and forensic analysis confirmed no customer data or customer system was in scope.
Grafana declined to pay the ransom, citing FBI guidance that payment does not guarantee data recovery and creates incentives for future attacks.
Why this keeps happening
Pull_request_target was designed for a specific, safe use case: running CI on a maintainer-controlled branch triggered by a pull request event, without checking out the forked code. The problem is that many legitimate CI patterns also need to check out the pull request code to run tests, linters, or build steps. Combining those two things creates the vulnerability.
GitHub has documented the risk. Multiple security researchers have written about it. The Pwn Request pattern has led to breaches at multiple organizations over the past three years. It keeps happening because the dangerous configuration looks nearly identical to the safe configuration in a YAML file, because many organizations adopt GitHub Actions workflows by copying examples that do not include the safety check, and because CI configuration is often treated as infrastructure-as-code without the same security review gate applied to application code.
What Grafana got right
Three things are worth noting as positive signals from this incident.
First, canary tokens worked. Grafana had deployed canary tokens that fired within minutes of the breach. This gave the security team a real-time alert without needing to rely on GitHub audit logs or anomaly detection in a SIEM. If you are not deploying canary tokens in your CI environment and your production secret stores, this incident is a good reason to start.
Second, Grafana refused to pay. The decision not to pay a ransom is not easy when source code is at stake. Grafana's postmortem makes the reasoning explicit: FBI guidance supports non-payment, and the forensic evidence showed no customer data was in scope.
Third, the postmortem is public. Many organizations breach and stay quiet. Grafana published a full account of what happened, how, and what changed. That transparency makes it easier for other organizations to audit their own workflows.
What to do today
Audit every workflow that uses pull_request_target. Search your GitHub organization for workflows with that trigger. For each one, verify that it does not also check out the pull request's code using actions/checkout with the pull request ref. If it does both, you have a Pwn Request-vulnerable workflow.
Scope repository secret access. No workflow that processes external pull requests should have access to production tokens, deployment keys, or other high-privilege credentials. Create a separate GitHub environment with scoped secrets for workflows that must interact with external contributions.
Deploy canary tokens in your CI environment. A canary token is a fake credential that does nothing except fire an alert when accessed. Place them alongside your real credentials in secret stores, CI environment variables, and configuration files. When an attacker extracts your environment dump, the canary fires before they use the real token.
Review recently added GitHub Actions. The Grafana breach involved a recently enabled Action. Changes to CI configuration are often lower-scrutiny than changes to application code. Apply the same pull-request review standards to workflow YAML as you do to production code.
Pin third-party Actions to a specific commit hash, not a tag. A tag can be moved; a commit hash cannot. If a dependency in your workflow is compromised and the tag is updated, you will execute the attacker's code. Pin by SHA.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want to talk through GitHub Actions security or CI/CD supply chain risk.