Grafana Labs Hit by GitHub Breach: Source Code Stolen, Ransom Demands Rejected

Grafana Labs has confirmed a breach of its GitHub environment via a 'Pwn Request' vulnerability. While attackers exfiltrated proprietary source code and attemp…

Grafana Labs Hit by GitHub Breach: Source Code Stolen, Ransom Demands Rejected

On May 16, 2026, Grafana Labs disclosed a security breach within its GitHub environment, stemming from a recently enabled GitHub Action configured with the pull_request_target event. An attacker exploited a vulnerability known as a "Pwn Request" to extract privileged tokens, gain access to private repositories, and attempt an extortion plot that the company has since rejected. The incident highlights the ongoing fragility of CI/CD supply chains, even for providers of critical observability tools.

The official notification was released through the company’s primary communication channels, confirming that the intrusion was detected by internal monitoring systems. Despite the blackmail attempt, Grafana chose transparency, publishing technical details to alert the global developer community. The event underscores how seemingly standard configurations can harbor fatal risks if not managed with rigorous isolation criteria.

Key Takeaways
  • The root cause was a GitHub Action enabled in recent weeks using the pull_request_target event, which exposed secrets during CI runs.
  • The attacker forked a repository, injected malicious instructions via a curl command, and exfiltrated environment variables to steal access tokens.
  • The intrusion was discovered only after one of Grafana’s thousands of distributed canary tokens was unexpectedly triggered.
  • The attacker replicated the operation against at least four additional private repositories before attempting monetary extortion.
  • Grafana has refused to pay the ransom, confirming that no customer data or personal information was compromised during the incident.

The Entry Point: Exploiting 'Pwn Request' via pull_request_target

The point of entry was a GitHub Action activated in recent weeks on a public repository. The workflow was triggered by the pull_request_target event, a mechanism that executes code within the context of the base repository, granting broad permissions, including access to secrets. This configuration, documented as a "Pwn Request," allows anyone who opens a pull request from a fork to execute code with elevated privileges.

According to the company's reconstruction, the attacker forked the target repository, injected malicious instructions via a curl command, and downloaded environment variables into a file encrypted with a private key. This allowed them to extract secrets stored in the CI/CD environment and obtain a GitHub token with extended privileges, paving the way into non-public internal repositories.

The Pwn Request vulnerability is a well-known threat in the supply chain landscape: it allows an attacker to modify code in a fork and have it executed in the context of the original repository via an apparently harmless pull request. Environment variables—which often contain API keys, access tokens, and cloud credentials—become readable by the CI/CD environment, turning a simple pull request into a high-profile backdoor for exfiltration.

It is necessary to clarify a terminology error that appeared in some early media reports: while some sources referred to the theft of a "database," technical evidence and Grafana's statements indicate that the exfiltration was limited to the codebase (source code) contained in the compromised repositories. There is no technical evidence that production databases containing sensitive user data were accessed or downloaded.

Lateral Movement: From Token Compromise to Private Repository Exfiltration

With the compromised token in hand, the attacker moved beyond the initial repository. After deleting the fork used for the initial access, they replicated the attack chain against at least four additional private repositories, downloading portions of the internal codebase. Grafana has not quantified the exact volume of the exfiltrated material, stating only that proprietary code was stolen using the privileges of the hijacked tokens.

Lateral movement within the organization occurred without the need for new intrusion techniques: the attacker simply reused the compromised GitHub token to clone additional repositories, exploiting the implicit trust the CI/CD system places in shared secrets. This pattern is particularly insidious because it bypasses traditional access controls by operating within a perimeter the system considers legitimate, protected by valid credentials.

Parallel to these events, claims emerged from a group calling itself "CoinbaseCartel," a name that has circulated in cybercrime forums since approximately September 2025. According to third-party analysts, the group has allegedly targeted nearly 170 victims across various industries. However, caution is required: Grafana Labs has not officially confirmed this attribution, and data regarding the group's history remains independently unverified.

The use of high-profile names and claims of hundreds of successful attacks are common tactics in extortion operations intended to increase psychological pressure on the victim. In Grafana's case, the CoinbaseCartel claim remains an unvalidated possibility. The company has prioritized forensic analysis and patching technical flaws over feeding the narrative of alleged attackers, following standard incident management protocols.

The Digital Tripwire: How Canary Tokens Triggered the Alert

Detection did not occur through standard infrastructure alarms but rather through one of thousands of canary tokens Grafana has deployed across its perimeter. When the attacker began exploring the compromised repository and attempted to use a decoy credential, the token generated an instantaneous alert, initiating the internal investigation. This detail highlights the tactical value of digital tripwires.

The use of canary tokens as an early warning system demonstrated both the merit of the defensive practice and its inherent limitations: the trigger tripped only after the attacker had gained initial access and begun exploration. While Grafana has not disclosed the specific technical details of the token, the sequence confirms that tripwires are essential for reducing dwell time, even if they cannot prevent the initial breach.

Grafana explained that it immediately invalidated all compromised credentials upon receiving the alert. Simultaneously, the security team removed the vulnerable GitHub Action and disabled all workflows on public repositories as a precautionary measure. While a precise timeline for the duration of the intrusion before discovery was not provided, the canary token's activation prevented longer-term persistence.

Extortion Refused and Remediation Strategy

After obtaining the codebase, the attacker contacted Grafana Labs to demand payment in exchange for not leaking the stolen code. The company categorically refused the blackmail. In justifying this decision, the company cited the well-known FBI position that "paying a ransom doesn’t guarantee you or your organization will get any data back."

"Our investigation has determined that no customer data or personal information was accessed during this incident, and we have found no evidence of impact to customer systems or operations" — Grafana Labs, official post on X

In the official communication published on its blog and X, Grafana assured stakeholders that the investigation found no access to customer data. The refusal to pay and the immediate disclosure of the facts represent a firm stance in an industry often tempted by silence. By providing the root cause and the countermeasures adopted, Grafana has offered the community a concrete case study on the risks of CI/CD misconfigurations and supply chain security.

Refusing to pay is not only an ethical choice but a long-term defensive strategy. By yielding to demands, companies often fund further attacks and mark themselves as high-value targets for future extortion. Grafana has chosen to invest resources into technical remediation and transparency, aiming to consolidate user trust despite the vulnerability in its development workflow.

Strategic Mitigations and Defensive Measures

Immediate Audit of GitHub Actions using pull_request_target: It is critical to remove this event trigger where it is not strictly necessary. Secrets must be restricted to workflows with a documented operational need. Replacing pull_request_target with the standard pull_request event on public repositories that accept external contributions eliminates the primary attack surface exploited in this incident.

Targeted Verification of Workflows and Recent Forks: Organizations should review execution logs for all recently enabled GitHub Actions, paying close attention to workflows triggered by external forks. Auditing forks created in recent months may reveal code injection attempts similar to those suffered by Grafana, allowing for the identification of undetected environment variable exfiltration.

Deployment of Canary Tokens or Honeytokens: Placing decoy credentials (such as fake AWS keys or inactive API tokens) within environment variables allows for rapid alerting. This practice significantly reduces time-to-detection. If an attacker abuses a CI/CD token and attempts to use these decoys, the security team is alerted immediately, limiting the potential damage of an existing compromise.

Implementation of Least Privilege for CI/CD Tokens: It is necessary to reduce the duration, scope, and permissions of secrets stored in GitHub. Consider using isolated execution environments without external network access for CI runs resulting from external contributions. Periodically reviewing the authorizations granted to automated workflows ensures that a single configuration error does not expose the company's entire information asset base.

This episode presents a significant paradox: an organization that builds its reputation on observability was hit by a single misconfiguration chain. The lesson applies not just to Grafana, but to anyone managing public codebases. While detection worked thanks to canary tokens, it only did so after the intrusion had occurred; the true challenge for the future remains preventing Pwn Requests before malicious code is ever executed.

Frequently Asked Questions

Is the CoinbaseCartel group truly responsible for the attack?

Responsibility has not been officially confirmed. While the group claimed the action by citing access to Grafana's data, the company has not validated this attribution. Information regarding CoinbaseCartel, including its alleged 170 victims and its 2025 formation, comes from the group’s own claims and has not been independently verified.

Why is the pull_request_target configuration considered so risky?

The risk lies in the fact that pull_request_target executes the workflow in the context of the base repository, not the fork. This grants the code within the pull request access to the original repository’s secrets and tokens. An attacker can inject scripts into the fork that, once the PR is triggered, read and exfiltrate the organization's private keys.

Do Grafana customers need to change their passwords or API keys?

According to Grafana Labs' official statements, no action is required from users. The internal investigation ruled out access to customer data, personal information, or production systems. The impact was limited to the source code of specific GitHub repositories. Users are encouraged to follow official channels for any further security updates.

Information has been verified against cited sources and is current at the time of publication.

Sources