May 19, 2026 · 8 min read
CoinbaseCartel Stole Grafana's Source Code With a Token Hidden in a Forked Repo—And the Canary the Defenders Planted Caught the Whole Operation
The attacker forked a public repo, dumped environment variables to an encrypted file with a curl one liner, then used the stolen tokens against four private repos. Grafana's incident response trigger was a single canary alert. The extortion demand failed.
What Grafana Disclosed
On May 18, 2026, Grafana Labs disclosed that an unauthorized party had obtained a token granting access to its GitHub environment and used it to download portions of its codebase. The company confirmed that "no customer data or personal information was accessed during this incident" and that "customer systems and operations" were unaffected. What the attacker walked away with was the source code—the same source code Grafana serves to more than 7,000 organizations, including roughly 70% of the Fortune 50 through its commercial offering.
The attribution claim came within hours. A data extortion crew calling itself CoinbaseCartel listed Grafana on its leak site and demanded ransom in exchange for not publishing the stolen code. Grafana refused. The company's public statement quoted the FBI's standard guidance that "paying a ransom doesn't guarantee you or your organization will get any data back" and that payment "offers an incentive for others to get involved in this type of illegal activity."
The Attack Chain Was Three Steps
The technical sequence Grafana's incident response team published is, as these things go, almost embarrassingly simple. It is also a near perfect template for how to abuse the modern GitHub Actions environment if you can get any developer or CI principal to run code in a private repo's context.
- Forked a Grafana repository. Forking public repos is universally allowed on GitHub. The fork lives under the attacker's own account, but the relationship to the parent enables certain workflow interactions that defenders rarely audit.
- Injected malicious code via a curl command. Inside the fork, the attacker modified an existing workflow file to add a curl invocation that exfiltrated the environment variables available to the GitHub Actions runner at execution time. The exfiltrated payload was encrypted with the attacker's private key before being sent out, so even a network analyst looking at the traffic in real time would not be able to read it.
- Triggered the workflow. Workflow execution on a fork can—depending on the parent repo's settings—inherit secrets if a maintainer ever runs an action that touches the fork's pull request. That step gave the attacker access to privileged tokens that were not supposed to leave Grafana's CI environment.
Once the tokens were extracted, the attacker deleted the fork to remove forensic evidence. They then used the stolen tokens to replicate the attack against four additional private repositories, this time without needing the public fork pivot. The pattern—public fork as initial vector, then escalation to private repos using credentials extracted from the first stage—mirrors the TanStack OIDC token theft chain that hit the JavaScript ecosystem last week and is increasingly the template for credential first supply chain attacks.
The Canary Token Saved Hours
The detail that everyone in security architecture should be circling: Grafana detected this attack because one of the company's thousands of deployed canary tokens fired. Canary tokens are decoy credentials—fake API keys, fake AWS credentials, fake database passwords—that look real but only exist to alert when used. Grafana scatters them through its codebase, environment configurations, and CI pipelines as tripwires. When the attacker's curl command dumped the environment to their encrypted file, one of the credentials in that environment was a canary. As soon as the attacker tested it, the alert fired.
Without the canary, the attack would have continued unnoticed for as long as the attacker chose to be quiet. The four follow on private repos would have been quietly scraped, the stolen tokens would have rotated through additional pivots, and the first signal Grafana received might have been the extortion email itself—at which point the data is already gone.
Canary tokens are not new. Thinkst's free canarytokens.org service has been around since 2015. What is new in the Grafana incident is the operational evidence that an organization the size of Grafana, with a mature security team, treats canaries as a primary detection layer rather than a clever side project. The hard cost of canaries is low—they are easier to deploy than a SIEM rule set—and the false positive rate is effectively zero because nobody but an attacker should ever touch a credential whose only purpose is to be touched by an attacker.
Who CoinbaseCartel Is
CoinbaseCartel is one of the more recently named groups in the extortion ecosystem. The crew launched in September 2025 and has claimed more than 100 victims, with public acknowledgment that they are "behind on many leaks"—an unusual admission that operational capacity, not victim availability, is the bottleneck. Threat intelligence vendors assess the group as an offshoot of three established crews:
- ShinyHunters, the data theft crew responsible for the Cushman & Wakefield Salesforce dump and dozens of other Salesforce based breaches over the past year.
- Scattered Spider, the social engineering specialists whose alleged leader pleaded guilty in April.
- LAPSUS$, the source code theft crew that hit Microsoft, Nvidia, and Okta in 2022.
The combination is well suited to the Grafana style attack: ShinyHunters provides the credential collection tradecraft, Scattered Spider supplies the social engineering and IT support fraud playbook, and LAPSUS$ brings the source code monetization model. CoinbaseCartel reportedly deploys an in memory tool called shinysp1d3r for encrypting VMware ESXi targets and disabling snapshots—a capability they did not need to use against Grafana but signals that their toolkit covers both data theft and operational disruption.
The Lesson For Any GitHub Org
The vector CoinbaseCartel used against Grafana is available against every GitHub organization that does not explicitly disable workflow execution from forks. The mitigations are concrete and well documented:
- In repository settings, set "Fork pull request workflows from outside collaborators" to "Require approval for all outside collaborators." The default lets first time contributor PRs run workflows with secrets after a single maintainer approval. Tighten it.
- Audit which workflow files reference repository secrets. The smaller the surface that ever sees a real credential, the smaller the surface a forked workflow can exfiltrate.
- Rotate any token that has ever been printed in a log, exposed to an action run, or shared across repos. The half life of a token in modern threat actor inventories is short—weeks, not months.
- Deploy canary tokens in CI environment variables. Even one canary per repo is more than zero. Thinkst's free service is sufficient to start; commercial offerings from Canary.tools scale to enterprise scope.
- Pin GitHub Actions to commit SHAs, not version tags. The Tinycolor and similar npm worms have demonstrated that an action you trust by tag today can be silently weaponized tomorrow.
The Refusal Matters
The most consequential decision Grafana made was not technical—it was the refusal to pay. CoinbaseCartel's business model depends on a sufficient fraction of victims paying that the cost of being noisy is worth it. Every public refusal—Grafana this week, DigiCert in March, others before that—erodes the unit economics of the group's operation. Whether the stolen Grafana source code shows up on the leak site this month or not, the company has signaled that the extortion threat is not coercive against them, and the next victim CoinbaseCartel approaches can point to Grafana as the example of a counterparty that walked away.
The 70% of the Fortune 50 that runs Grafana code in some form is not directly at risk from the source code being public—the company is open source first, so most of the code already is. The risk that actually matters is whether the stolen private repos contained vulnerability disclosures that have not been remediated yet. Grafana has not addressed that question publicly. The answer, in any organization that handles source code, should always be: assume the worst, accelerate the patches you were planning to ship next month, and audit the canary inventory before the next time it has to do its job.