Grafana Refused the CoinbaseCartel Ransom. The pull_request_target Pwn Request Just Hit Its Second Major Vendor.
Grafana caught a CoinbaseCartel breach via canary token, traced it to a pull_request_target Pwn Request, and refused to pay — the second Pwn Request hit in three weeks.
A canary token caught the breach. A pull_request_target workflow caused it. CoinbaseCartel demanded payment. Grafana said no — and the second GitHub Pwn Request hit in three weeks lands on the docket.
NEW YORK, NY — Grafana Labs disclosed this week that an unauthorized party obtained a GitHub token granting access to its GitHub environment and downloaded its private codebase. The intrusion was detected when one of Grafana's deployed canary tokens triggered an alert. The root cause was a recently enabled GitHub Action containing a Pwn Request vulnerability — a misconfiguration in a workflow triggered on pull_request_target events that gave external contributors access to production secrets during CI runs. The attacker forked a Grafana repository, injected JavaScript via a crafted branch name, exfiltrated a privileged token, deleted the fork to cover tracks, and then replicated the attack against four additional private repositories. CoinbaseCartel — a data-theft-and-extortion group assessed to be an offshoot of the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems — claimed responsibility and demanded payment. Grafana refused, citing FBI guidance that paying doesn't guarantee recovery and incentivizes more attacks.
The pull_request_target Pwn Request pattern is the second major vendor incident in three weeks. The May 11 Mini Shai-Hulud campaign against TanStack exploited the same workflow trigger; this is the second time the same root cause class has reached a major vendor's codebase. For CISOs running GitHub Actions, that's no longer an obscure misconfiguration — it's a documented, repeatedly exploited attack vector with a known weaponization pattern. Grafana's refusal to pay also marks a public contrast against Instructure's recent ShinyHunters settlement, drawing the ransom-payment ethics line at a different point on the same week.
How a Branch Name Became an Exploit
The pull_request_target GitHub Actions trigger exists because some workflows legitimately need to run against the base repository's secrets — running tests against the maintainer's deployment environment, posting status updates back to the PR, gating merges on integration tests that need credentialed cloud access. The danger is that pull_request_target runs the workflow definition from the base branch but checks out the head branch's code by default. If the workflow shell-interpolates any value from the fork — branch name, PR title, author username — the fork's author can inject arbitrary commands or scripts.
Grafana's attacker crafted a branch name that escaped the literal context in the workflow and executed JavaScript to exfiltrate the workflow's secrets to an external endpoint. The same primitive — a fork-controlled string flowing into an unescaped shell or script context — is what TeamPCP used in the Mini Shai-Hulud campaign against TanStack three weeks ago. The two incidents are not the same operator, but they're the same playbook against different victims, which is what makes the pattern operationally important.
The Canary Caught It
Grafana's detection isn't a workflow audit, an IDS rule, or an SAST finding. It's a canary token — a deliberately fake credential left in a place an attacker is expected to find and use. When the attacker exfiltrated and exercised the captured credential, the canary fired and alerted the global security team within seconds. Grafana has thousands of these tokens deployed across its environment.
This is the operational counterpoint to the 'attackers dwell for months' headline. Dwell time is long when the only detection is downstream behavioral anomaly. Dwell time is short when the credentials themselves are tripwires. The lesson for vendors with private source code as a tier-one asset is structural: deploy canary tokens across your build infrastructure as a default control, not a maturity-level-four aspiration. Grafana caught a real attacker because they did this two years ago.
CoinbaseCartel and the Payment Refusal
CoinbaseCartel emerged in September 2025 and has accumulated approximately 170 named victims across healthcare, technology, transportation, manufacturing, and business services. Researchers assess it as an offshoot of the broader ShinyHunters / Scattered Spider / LAPSUS$ ecosystem — the same talent pool that ran the Instructure Canvas extortion and the Comcast Xfinity Citrix Bleed exposure. The model is consistent: steal data, no encryption, threaten leak, demand payment.
Grafana's refusal to pay is the public counterweight to Instructure's recent settlement. Both decisions are defensible — Instructure's was driven by Canvas-customer-base pressure and a defensible legal posture; Grafana's is driven by no customer data exposure and FBI public guidance. The strategic point for the CISO community is that the ransom-payment decision is now a documented strategic position, not an operational tactic. Boards are going to ask what their organization's policy is, and the answer should be in writing before the call from the threat actor.
The CyberSignal Analysis
Signal 01: pull_request_target Is Now a Documented Exploitation Pattern
Two major-vendor incidents in three weeks against the same GitHub Actions trigger crosses the threshold from edge-case misconfiguration to documented exploitation pattern. The Mini Shai-Hulud TanStack compromise was the first public proof. Grafana is the second. The structural problem is that pull_request_target's design — workflow from base, code from head — is unintuitive even to senior developers, and the defaults make insecure usage easier than secure usage. GitHub's documentation has improved, but the existing population of workflows enabled before the documentation update is the actual attack surface. Every CISO with GitHub Actions in production should treat this as a known-exploited vulnerability class with an active campaign, not a hypothetical risk.
Signal 02: Two Vendors, Two Answers, Same Week
Instructure paid. Grafana refused. Both happened in May 2026, in the same threat-actor ecosystem, against vendors of similar scale. The defender community now has two public data points on the ransom-payment decision tree — and the differences in their reasoning are instructive. Instructure faced a customer-base demand to keep specific Canvas data off the leak forums; Grafana faced no customer-data exposure and could absorb the codebase leak as a competitive impact rather than a customer impact. The policy implication is that the right answer depends on what's actually at risk: customer trust versus reputation, regulatory exposure versus competitive disclosure. Boards setting payment policy in advance need that decomposition explicit, not deferred to incident-response stress.
What to Do This Week
- Audit every workflow in your GitHub organization that uses the pull_request_target trigger. Treat each one as a known-exploited misconfiguration until proven otherwise.
- Where pull_request_target is required, follow the GitHub security hardening guide: scope GITHUB_TOKEN permissions narrowly, never interpolate fork-controlled values into shell or script context, and use environment protection rules for any secret access.
- Deploy canary tokens across your build infrastructure. Thinkst Canary, fake AWS keys in repositories, fake API keys in CI environment — the cost is low and the detection latency is seconds.
- Document your organization's ransom-payment policy in advance. Define the criteria — customer data exposure, regulatory triggers, operational continuity, reputational threshold — and get board sign-off now, not during an incident.
- Engage law enforcement early on any extortion event. FBI Cyber Division for US organizations; equivalent national CERT for others. Grafana cited FBI guidance directly in its public statement — that's the precedent.
