Grafana Labs: Stolen GitHub Token Leads to Source Code Theft and Ransom Demand

Grafana Labs, which makes the Grafana observability platform, says an unauthorised party got hold of a token that gave access to its GitHub environment. The attacker used it to download the company's source code, including proprietary code that is not part of Grafana's open-source releases, and then demanded a ransom in exchange for not publishing it. According to Certizon and kaplradio.org, Grafana refused to pay and says no customer data was exposed and customer systems and operations were not affected. Grafana's position is currently known only through secondary write-ups that quote it. No regulator filing has been published. No one has said how much code was taken or how long the attacker had access.

What Happened

Certizon and kaplradio.org agree on the main sequence of events:

• An unauthorised party obtained a token that worked against Grafana Labs' GitHub environment.
• The attacker used it to reach Grafana's source code repositories and download code.
• The attacker then threatened to release the code publicly unless Grafana paid.
• Grafana declined. It cited the FBI's published guidance against paying ransoms and its own finding that customer data and customer systems were not affected.
• Grafana carried out a forensic investigation, invalidated the compromised credentials and added further security measures.

Kaplradio.org says the extortion was carried out by CoinbaseCartel, which it describes as a crime group that focuses only on stealing data and extorting victims, and does not encrypt systems the way traditional ransomware groups do. Grafana has not attributed the attack to anyone, and no other publication has confirmed the CoinbaseCartel link. Treat it as unverified.

Grafana has a history with this kind of attack. Btw.media, reviewing a 7 October guide on the LACNIC blog, describes a separate 2025 incident. In that case a vulnerable GitHub Actions workflow exposed a limited number of tokens, and an attacker who took secrets from Grafana's repositories tried to use an AWS key that turned out to be a canary (a decoy credential set to raise an alert). Grafana said at the time that the activity stayed within its automation systems and did not reach production or release artifacts. Nothing published so far says whether the token in the current incident came from a similar route. The two incidents should be treated as separate unless Grafana says otherwise.

What Was Taken

• Source code: Grafana's repositories, including proprietary code not available in its open-source releases. Certizon says the exposure risk is partly reduced because much of Grafana's codebase is already public.
• Customer data: None, according to Grafana as quoted by Certizon and kaplradio.org.
• Volume: Not disclosed. No repository count, data size or list of affected products has been published.

What matters most in stolen source code is what else might be inside it: hardcoded secrets, internal URLs, infrastructure-as-code and CI configuration. Grafana has not said whether any credentials were found in the stolen repositories or rotated as a result. The company has only said that it invalidated the compromised credentials.

Why It Matters

• One token was enough. This attack needed no exploit and no malware. A single credential with broad repository access was enough to take a commercial codebase.
• Extortion without encryption keeps growing. If the CoinbaseCartel attribution is right, this follows a model where attackers skip encryption and only steal and threaten to leak. That works against software companies even when operations are never disrupted.
• Stolen code helps attackers find bugs. Grafana runs in a huge number of monitoring setups. Its recent security advisories show the kind of flaws that matter on these deployments, though none of them has been linked to this breach:
• CVE-2026-103506 (CVSS 8.9), reported by TrustList: exposes SSO client secrets when an experimental flag is enabled in 13.2.
• CVE-2026-88967 (CVSS 7.7): leaks an Azure Monitor token.
• CVE-2026-81841: paused public dashboards still expose data source configuration.
• CVE-2026-13719: alert rules leak across folder permissions.
• CVE-2026-75889 in Grafana Alloy, described on DEV Community: lets a crafted configuration read any local file and send it out as an authorization header.

Proprietary code in an attacker's hands makes it easier to find the next flaw like these. - Attackers move fast once inside. In a separate case, ENTRYZERO reports that the Dutch Institute for Vulnerability Disclosure (DIVD) was breached in Q3 2026 by what appeared to be an autonomous AI agent. It moved from its first foothold to internal services and copied data out within minutes. Defenders should assume a stolen developer token will be used just as quickly.

The Attack Technique

The confirmed entry point is a compromised GitHub access token. The type of token, how it was stolen and what permissions it had have not been disclosed. Grafana's 2025 incident shows one common route: CI/CD workflows that expose tokens to untrusted input. Developer endpoints and secrets committed to repositories are other common routes, but none of these has been confirmed for this incident.

The canary detail from 2025 is a useful lesson about timing. Btw.media notes that Grafana's own conference account separates four markers: an attack event at 04:30, a canary firing during TruffleHog validation at 06:15, a response at 08:00 and log review at 11:00. That account gives no timezone and does not treat the first marker as the moment of initial access. A canary only fires when the attacker tests the decoy, which can be well after the real secrets were taken.

What Organizations Should Do

1. Replace long-lived personal access tokens. Use fine-grained, short-lived credentials such as GitHub Apps or OIDC federation, limited to specific repositories. Enforce expiry.
2. Harden CI/CD workflows. Audit GitHub Actions for pull_request_target and similar triggers that run untrusted code with secrets available. Pin actions to commit SHAs and set default GITHUB_TOKEN permissions to read-only.
3. Watch for bulk cloning. Alert on unusual git clone or archive download volume, access from new IP addresses or ASNs, and token use outside normal hours, using GitHub audit logs or SIEM ingestion.
4. Scan private repositories for secrets before an attacker does. Treat any stolen repository as a full secrets exposure and rotate everything found in its history, not just the token that was used.
5. Plant canary credentials, but understand their limits. Decoy keys give early warning, but they only show when the attacker tests a key, not when access began. Pair them with log retention long enough to rebuild the full timeline.
6. Patch Grafana deployments regardless of this breach. Apply the fixes for CVE-2026-103506, CVE-2026-81841, CVE-2026-13719 and the Alloy file-read flaw. Rotate SSO client secrets where the kubernetesSsoSettingsApi flag was ever enabled.

Sources: Grafana Labs GitHub Breach: One Stolen Token, a Ransom Demand, and... | Breaches Due To Unpatched Vulnerabilities | Grafana's GitHub Token Breach: What Happened and How They Responded... | Grafana fixes SSO secret exposure and Azure token leak flaws - Trus... | LACNIC’s Canary Guide and Grafana’s Detection Timeline | Grafana Alloy's bearerTokenFile Read Any Local File and Sent It as... | CVE-2026-81841: Paused shared dashboard access tokens still expose... | CVE-2026-13719: Alert rules in restricted folders disclosed via the...