Grafana Labs disclosed on May 16-17, 2026 that a data extortion group calling itself CoinbaseCartel exfiltrated source code from five private GitHub repositories after exploiting a “Pwn Request” misconfiguration in a recently-enabled GitHub Actions workflow. The breach was caught by one of thousands of canary tokens Grafana has seeded across its environment, and the company has refused to pay the ransom demand.
The attack pattern is the same one tearing through the open-source ecosystem this quarter: a workflow triggered on pull_request_target that ran untrusted code from forked PRs while still having access to production secrets. CoinbaseCartel forked one of Grafana’s public repositories, pushed a PR containing a malicious curl step, and used it to dump the runner’s environment variables to a file encrypted with the attacker’s public key. They then deleted the fork to wipe the audit trail. The compromised tokens were enough to clone four additional private repos before a canary token embedded in one of them phoned home and woke up the global security team.
No customer data was touched. Grafana Cloud, Grafana OSS, Loki, Mimir, Tempo, Pyroscope, and the rest of the product surface run in separate environments with their own credential boundaries, and the company says no production systems, build artifacts, or release infrastructure were accessed. The stolen material is source code only — much of which is already open source — though the four private repos presumably contain at least some pre-release work, internal tooling, and embedded secrets that now need rotation.
Why pull_request_target keeps eating CI pipelines
The pull_request_target trigger exists because maintainers wanted a way for workflows on PRs from forks to have write access to the upstream repo (labeling, commenting, autoresponses). The trade-off is that it runs in the base repository’s context, with the base repo’s secrets, while checking out code that an external contributor controls. If the workflow does anything beyond inspecting the PR metadata — running tests, building, lint with autofix, anything that executes contributor-controlled code or scripts — the attacker controls a process that holds your production credentials.
This is the same primitive that TanStack got hit with last week (Mini Shai-Hulud Wave 4), the same one TeamPCP rode through Mistral AI, UiPath, OpenSearch, and Guardrails AI on May 12, and the same one that has been quietly burning through GitHub Actions configurations since GitHub published a deprecation-style advisory about it in 2021. The vulnerability class is older than most current GitHub Actions practitioners. The advisories are old. The exploit code is old. And it still keeps working because the misconfig sneaks back in every time a workflow is rewritten or a new repository is bootstrapped from a template.
Detection: canary tokens did the work
Grafana’s own engineering blog from August 2025 detailed how the team deploys canary tokens — fake credentials, fake API keys, fake AWS IAM roles seeded into repos, configs, and environment dumps that page on use. The published guidance becomes load-bearing on this incident: the company says the very first signal of intrusion was a canary trip, not a SIEM alert, not a token-usage anomaly from GitHub, and not a third-party threat feed. By the time CoinbaseCartel had cloned the fifth repo and tried to use one of the canary credentials embedded in it, Grafana was already revoking the real ones.
If you take one operational lesson from this incident, it is this: canary tokens in CI environments work, and they work specifically against the failure mode where an attacker holds a real-looking credential and has no other way to tell which ones are wired to detection. Grafana caught a group that has burned ShinyHunters-tier infrastructure on this attack chain, and they caught it on the second hop.
CoinbaseCartel and the extortion economy
CoinbaseCartel is a data extortion crew that surfaced in September 2025, tied by reporting to the loose ShinyHunters / Scattered Spider / LAPSUS$ ecosystem that has spent the last 18 months pivoting away from encryption-based ransomware toward source-code theft, customer-database theft, and pure-extortion plays against vendors. The group demanded payment in exchange for not publishing Grafana’s stolen repositories. Grafana publicly refused, citing FBI guidance that payment doesn’t guarantee data recovery and incentivizes follow-on attacks. The ransomware.live listing for the incident is now live as a public shaming page.
What to do right now
Audit every workflow in every repository for pull_request_target triggers. If a workflow uses that trigger, it must not check out the head ref of the PR, must not run any contributor-controlled scripts, and must not call any reusable action whose code lives in the PR. The safe pattern is pull_request (no privileged secrets) plus a separate, manually-triggered or workflow_run-triggered job that does anything sensitive after the PR is reviewed.
Rotate every secret that has ever been exposed to a pull_request_target workflow on a repo with public forks. Assume disclosure. Pull GitHub’s audit log for the last 90 days and look for clone events from IPs you don’t recognize against repos where the trigger has been enabled.
Seed canary tokens into CI environments, env-var dumps, .env.example files, and internal Terraform. The Grafana blog from August 2025 is the cleanest open-source writeup of how to do this without generating false positives. The tokens have to be plausible — same prefix, same length, same surrounding context — or attackers learn to skip them.
Watch for Grafana Labs’ own postmortem, expected in the coming days. The five-repo blast radius and the canary-led detection make this one of the more instructive disclosures of the year so far.