Grafana Labs Security Breach: Hackers Stole the Entire Codebase

Grafana Labs Security Breach: Hackers Stole the Entire Codebase

A threat actor gained unauthorized access to Grafana Labs' GitHub environment, downloaded their entire private codebase using a stolen privileged token, and then demanded a ransom payment. Grafana refused to pay.

Field	Detail
Disclosed	May 16, 2026
Target	Grafana Labs GitHub Environment
Attack Vector	Pwn Request via pull_request_target GitHub Action
What Was Stolen	Full private codebase (downloaded)
Ransom Demanded	Yes, Grafana refused to pay
Alleged Group	CoinbaseCartel
Customer Data Exposed	No
Current Status	Contained · Credentials invalidated

Table of Contents

1. What Happened in the Grafana Labs Security Breach

2. How the Attack Workedmc

3. mcUnderstanding the CI/CD Security Risk

4. Who is CoinbaseCartel?

5. Extortion Attempt After the Code Theft

6. Impact of the Grafana Labs Breach

7. Grafana Labs' Incident Response

8. Community and Industry Reactions

9. Lessons Learned

10. The Growing Threat of Software Supply Chain Attacks

11. Our Technical Analysis

12. Security Checklist

13. Complete Incident Timeline

The Grafana Labs security breach disclosed on May 16, 2026 sent shockwaves through the open source and cybersecurity communities. An unauthorized attacker used a misconfigured GitHub Action to steal a privileged token, then quietly downloaded the company's entire private codebase before anyone noticed. When Grafana eventually did notice, thanks to a triggered canary token, the damage was already done.

This incident matters beyond Grafana itself. It exposes a class of attacks that thousands of companies are vulnerable to right now, without even knowing it. CI/CD pipelines, the automated systems developers rely on to build and ship software, have quietly become one of the most dangerous attack surfaces in modern infrastructure.

This article breaks down exactly what happened, how the attacker pulled it off step by step, who is responsible, and what every developer and security team should do today.

What Happened in the Grafana Labs Security Breach

What Is the Grafana Labs Security Breach? A Complete Overview

Grafana Labs is the company behind Grafana, one of the most widely used open source observability and monitoring platforms in the world. Grafana Cloud, Grafana Enterprise, and the open source Grafana stack power dashboards for thousands of organizations globally. This is not a small player  this is core infrastructure for countless engineering teams.

On May 16, 2026, Grafana Labs publicly disclosed that an unauthorized party had obtained a token granting access to their GitHub environment. That single token gave the attacker enough access to download the company's entire private codebase. The company confirmed the breach only after one of its thousands of deployed canary tokens was triggered, which immediately alerted the global security team.

How Was the Breach Discovered?

A canary token is a type of digital tripwire. It looks like a real credential or file, but it is a trap. When someone uses it or accesses it, it sends an alert back to the security team. Grafana Labs had thousands of these deployed across their environment a smart detection strategy that ultimately saved them from remaining completely blind to the intrusion.

When the canary token fired, the security team knew within moments that someone was inside. That detection kicked off an immediate global response.

Unauthorized Access Detected

• Detection method: A triggered canary token from Grafana's large deployed network

• What the attacker had: A privileged GitHub token with broad repository access

• What the attacker did: Downloaded the private codebase in its entirety

• How long before detection: The timeline suggests the attack was swift and methodical

How the Attack Worked 

How Did Hackers Access Grafana's GitHub Codebase? The "Pwn Request" Attack Explained

The root cause was a recently enabled GitHub Action that contained a "Pwn Request" vulnerability. This is a specific type of misconfiguration in how GitHub Actions handles workflows triggered on pull_request_target events.

What is a "Pwn Request" Vulnerability?

Trigger	Runs in Context of	Access to Secrets?
pull_request	Forked repo (untrusted)	No
pull_request_target	Base repo (trusted)	Yes

The pull_request_target trigger was designed to allow maintainers to run workflows that need repository secrets, things like deployment keys or API tokens, even when a pull request comes from an external fork. The problem is that if the workflow runs code from the pull request itself, it means an attacker who submits a malicious pull request can get that code to run inside a privileged, trusted environment with full access to production secrets.

That is exactly what happened to Grafana

Step-by-Step Breakdown of the Attack

Step 1: Fork a Grafana Repository The attacker forked a public Grafana repository on GitHub. Forking is a normal, expected action in open source development. Nothing looked suspicious at this stage.

Step 2: Inject a Malicious curl Command The attacker modified the forked code to include a malicious curl command. When the vulnerable GitHub Action workflow triggered, it ran this command inside the trusted CI environment.

Step 3: Dump and Encrypt Environment Variables The malicious code dumped all environment variables, which included privileged GitHub tokens, into a file. That file was encrypted with a private key controlled by the attacker. This is a clean technique: encrypt the stolen data immediately so it cannot be intercepted in transit.

Step 4: Extract the Privileged Token With the environment variables captured, the attacker now had a GitHub App token with access to Grafana's private repositories.

Step 5: Download the Private Codebase Using the stolen token, the attacker accessed and fully downloaded Grafana's private codebase. The attack then expanded, the compromised credentials were used against four additional private repositories.

Step 6: Delete the Fork to Cover Tracks After the attack was complete, the attacker deleted their fork. This removed the most visible evidence of what had happened and bought time before detection.

Why is pull_request_target So Dangerous?

Most developers do not know this risk exists. The pull_request_target trigger was added to GitHub Actions specifically to handle situations where CI workflows needed to run with elevated permissions even for external PRs. The documentation does warn about this but warnings in documentation get missed, especially by teams moving fast.

The real-world danger: if any code path in the workflow runs code from the pull request (even indirectly, through a checkout step or a tool invocation), an external attacker effectively has code execution inside your trusted environment with all of your secrets.

Understanding the CI/CD Security Risk

What is a CI/CD Pipeline?

CI/CD stands for Continuous Integration and Continuous Deployment. In plain terms: it is the automated system that takes developer code, tests it, builds it, and ships it to production often without any human manually running a command.

Every time a developer pushes code or opens a pull request, the CI/CD pipeline kicks off automatically. It runs tests, checks code quality, and can even deploy new versions of software. This automation speeds up development enormously. It also creates new attack surface that did not exist when deployment was a manual process.

Why GitHub Actions Can Become Dangerous

GitHub Actions is the CI/CD platform built directly into GitHub. It is convenient, tightly integrated, and used by millions of repositories. It is also regularly misconfigured.

Key risks:

• Secret exposure: Workflows often need API keys, deploy tokens, and cloud credentials. Those secrets live inside the workflow environment.

• Misconfigured permissions: Workflows can inadvertently grant too much access to code from untrusted contributors.

• Third-party actions: Many workflows use pre-built community actions. A compromised community action can steal secrets from every workflow that uses it.

• pull_request_target misuse: As we have seen with Grafana, this single configuration choice can open a door to production credentials for any attacker willing to submit a pull request.

Who is Behind the Grafana Hack? Inside CoinbaseCartel 

CoinbaseCartel: Who Are They?

Reports from Hackmanac, Ransomware.live, Halcyon, and Fortinet FortiGuard Labs attribute this attack to a cybercrime group called CoinbaseCartel. Despite the name, they have no connection whatsoever to the legitimate cryptocurrency exchange Coinbase.

CoinbaseCartel emerged in September 2025. Security researchers assess the group as an offshoot of the broader ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems, a loose network of English-speaking cybercriminal actors known collectively as "The Com."

Threat Actor Profile

Field	Detail
Group	CoinbaseCartel
Active Since	September 2025
Method	Data Theft + Extortion (No Encryption)
Known Victims	170+ across multiple sectors
Linked Groups	ShinyHunters, Scattered Spider, LAPSUS$
Target Industries	Tech, Healthcare, Transportation, Manufacturing, Finance
Ransom Model	Steal data, demand payment, threaten public release

How Does CoinbaseCartel Operate?

This group does not use ransomware encryption the way traditional ransomware gangs do. They skip the encryption step entirely. Their model is simpler and, in some ways, harder to defend against:

• Steal the data. Get inside, exfiltrate valuable files, code, or customer records.

• Demand payment. Contact the victim with a ransom demand.

• Threaten to publish. The leverage is the threat of releasing the stolen data publicly or selling it.

They operate a dark web leak site and use staged disclosures, releasing small sample files first to prove they have the data, then escalating to threaten full publication if payment is not made. Victims get 48 hours to respond and a 10-day window to pay before data is published.

Since September 2025, CoinbaseCartel has claimed over 170 victims across healthcare, technology, transportation, manufacturing, and business services. Within their first few months of operation, they landed in Bitdefender's Top 10 Ransomware Groups list, a remarkably fast climb.

Connection to ShinyHunters, Scattered Spider, and LAPSUS$

These groups orbit within a broader ecosystem called "The Com" a largely English-speaking, loosely organized cybercriminal community that researchers describe as functioning more like a subculture than a traditional organized crime outfit. Actors share tools, trade access credentials, and collaborate on high-value targets.

ShinyHunters specializes in large-scale data exfiltration from cloud platforms. Scattered Spider is known for sophisticated social engineering and initial access operations. LAPSUS$ made headlines for breaching major technology companies using credential theft and insider manipulation. CoinbaseCartel appears to draw from this talent pool, operating as a focused data extortion arm within that broader ecosystem.

Extortion Attempt After the Code Theft

Hackers Demanded Ransom: Here's Why Grafana Labs Refused to Pay

After downloading Grafana's private codebase, the attacker escalated. They contacted Grafana Labs and demanded payment in exchange for not releasing the stolen source code publicly. This is the standard CoinbaseCartel playbook steal the data, then weaponize it.

Why Grafana Refused

Grafana's response was direct and grounded in established guidance. The company cited the FBI's published guidance on ransomware payments. The FBI's position is clear: paying a ransom does not guarantee that stolen data will be returned or destroyed. It also incentivizes attackers to continue these operations because it proves the business model works.

Paying would have:

• Funded further attacks on other companies

• Provided no guarantee the stolen code would not be published anyway

• Set a precedent that Grafana would negotiate under extortion

• Potentially violated regulations depending on who the threat actors are

The decision not to pay was the right call. It is also the harder call to make in the moment when stolen source code, the result of years of engineering work is being held hostage.

What Did Grafana Do Instead?

Rather than paying, Grafana immediately shifted into containment and response mode:

• Compromised credentials were invalidated without delay

• The vulnerable GitHub Action was removed from the repository

• All workflows across public repositories were disabled

• A forensic investigation was launched

• A public disclosure statement was issued promptly

The public disclosure happened the same day the ransom demand came in. Grafana chose transparency over silence, a decision that drew significant praise from the security community.

Impact of the Grafana Labs Breach

What Was Actually Stolen? Assessing the Real Damage

The most alarming part of any breach is figuring out what was actually taken. Here is what the investigation found.

Was Customer Data Exposed?

No. Grafana's investigation confirmed that no customer data or personal information was accessed during the incident. There is no evidence of any impact to customer systems or operations. For a platform used by thousands of organizations to monitor critical infrastructure, this is the most important finding.

Why Codebase Theft Is Still Serious

Even without customer data being exposed, having your entire private codebase stolen is a significant security event. Here is why:

• Architecture exposure: Attackers can study how the software is built internally — the kind of knowledge that makes future attacks much easier.

• Embedded secrets: Source code sometimes contains hardcoded API keys, credentials, or internal service endpoints that developers meant to remove.

• Supply chain risk: If an attacker understands how Grafana builds and packages software, they could theoretically craft a targeted supply chain attack against Grafana's users.

• Signing keys and build infrastructure: Any code signing keys or deployment automation secrets stored in or near the codebase could have further exposure risk.

Risk Matrix

Risk Category	Level	Status
Customer Data	Low	Not Accessed
Source Code	High	Downloaded
Production Systems	Low	No Evidence
Signing Keys / Secrets	Medium	Under Investigation
Supply Chain Risk	Medium	Potential Future Risk

The supply chain risk is worth watching closely. Grafana Cloud, Grafana Enterprise, and the open source Grafana stack all have extensive user bases. Any future attack that leverages knowledge of Grafana's internal systems to compromise those users downstream would be far more damaging than this breach itself.

Grafana Labs' Incident Response

Immediate Security Actions Taken

Grafana's response speed was notable. Once the canary token alert fired:

• Privileged credentials were revoked immediately : the stolen token was invalidated before the attacker could use it further

• The vulnerable GitHub Action was removed : the root cause was eliminated from the environment

• All public repository workflows were disabled : a broad kill switch to prevent any similar exploitation across their other repositories

• A global security team response was initiated : the canary token alert was specifically designed to trigger this

Internal Investigation and Post-Incident Review

The forensic analysis is ongoing. Grafana has committed to sharing additional findings from the post-incident review once the investigation is complete. This level of transparency from a company that just suffered a breach is worth acknowledging many companies would have stayed quiet for weeks.

Community and Industry Reactions

Security Researchers Respond

The security community was quick to respond after Grafana's disclosure. Researchers pointed out that the pull_request_target vulnerability has been documented as dangerous for years. Despite published warnings from GitHub itself and multiple security researchers, many open source projects continue using it incorrectly. The Grafana incident gives those warnings new urgency.

The broader conversation quickly expanded beyond Grafana to software supply chain security in general. CI/CD pipelines are increasingly viewed as a primary attack surface in 2026, yet security investment in this area often lags behind the sophistication of attackers.

Mixed Reactions Online

The community reaction was layered:

• Praise for transparency: Most security professionals acknowledged Grafana for disclosing quickly, publicly, and with specifics. That kind of behavior should be the norm, not the exception.

• Criticism about monitoring gaps: Some pointed out the irony Grafana Labs builds one of the world's most widely used monitoring and observability platforms, yet missed this attack until a canary token fired. The company's own product exists to detect anomalies in systems.

• Industry concern: The incident reignited debate about whether open source maintainers have enough resources to properly secure their own development infrastructure.

Lessons Learned From the Grafana Labs Security Breach

Importance of Securing GitHub Actions

This incident is a masterclass in CI/CD misconfiguration. The lessons for GitHub administrators and DevSecOps teams are specific and actionable.

Proper workflow permissions:

• Never use pull_request_target unless you genuinely understand the security implications

• If you must use it, never check out or execute code from the pull request within that workflow

• Set explicit permission scopes on all workflows use the minimum necessary

Secret isolation best practices:

• Store production secrets in dedicated secret management systems, not directly in GitHub Secrets where a workflow misconfiguration can expose them

• Use OpenID Connect (OIDC) token authentication instead of long-lived static credentials wherever possible

• Rotate tokens and secrets regularly stolen credentials should have short lifespans

Continuous auditing:

• Regularly review all GitHub Actions workflows, especially recently added or modified ones

• Use automated tools to scan for known dangerous workflow patterns

• Track every new third-party action introduced into your workflows

Why Open Source Projects Are High-Value Targets

Grafana is an open source project trusted by thousands of organizations. This makes it an attractive target for exactly the kind of supply chain thinking attackers are increasingly applying. A compromise in Grafana's build or deployment process could theoretically affect every downstream user.

Trust relationships in software supply chains create multiplier effects. One breach of a trusted upstream project potentially exposes hundreds or thousands of dependent systems.

Best Practices Organizations Should Follow

• Least privilege access: Every GitHub token, service account, and API key should have only the permissions it needs for its specific job nothing more.

• Token rotation: Tokens should expire and rotate automatically. A stolen token that expires in 24 hours causes far less damage than one that works indefinitely.

• CI/CD hardening: Pin GitHub Actions to specific commit SHA hashes, not floating version tags. A tag can be hijacked; a commit hash cannot.

• Monitoring and detection: Deploy canary tokens widely, as Grafana did. They are cheap to implement and fast to alert. Without them, this breach might have gone undetected for weeks.

The Growing Threat of Software Supply Chain Attacks

Grafana is Not Alone: The Rising Danger to Developer Infrastructure in 2026

The Grafana Labs security breach is not an isolated incident. It is part of a clear and accelerating trend. Attackers have realized that targeting developer infrastructure the tools, pipelines, and credentials that build software, can provide access to far more targets than attacking any single company directly.

Rise of DevOps and Pipeline Exploits

Recent years have seen a significant increase in attacks targeting CI/CD infrastructure:

• The node-ipc npm package incident poisoned a widely used library affecting millions of projects

• Multiple major cloud providers have documented stolen CI credentials being used for cryptomining and data exfiltration

• GitHub Actions supply chain attacks have become a documented attack category with multiple published case studies

• The 3CX supply chain attack demonstrated what a compromised build process can mean at enterprise scale

In 2026, developer tools are a primary target. Attackers know that a developer workstation or CI environment often has access to dozens or hundreds of systems at once.

The Rise of Encryptionless Extortion

Traditional ransomware groups encrypt your files and demand payment to restore access. CoinbaseCartel and similar groups have shifted to a simpler and arguably more insidious model: they skip the encryption entirely.

Why? Encryption is complicated. It requires deploying malware, maintaining infrastructure, and dealing with decryption key management. Data theft alone is easier, and the leverage of threatening to publish sensitive data can be just as effective sometimes more so than locking systems.

This model also means there is no "pay and get your systems back" outcome available. If they publish the data, payment changes nothing. It is a shift that demands a completely different defensive posture.

Past Grafana Security Incidents

This was not Grafana's first experience with GitHub workflow vulnerabilities. In a 2025 post-incident review, Grafana disclosed that a previous GitHub workflow vulnerability had exposed a limited number of tokens. The 2026 incident suggests that lessons from that earlier event were not fully implemented across all repositories.

Patterns matter in security. When a class of vulnerability causes an incident once, every similar configuration in the environment becomes a priority to review. This is harder than it sounds in large open source projects with many repositories and contributors, but it is necessary.

Who Else is Vulnerable?

The honest answer is: many organizations. Any team that

• Uses GitHub Actions with pull_request_target triggers

• Accepts external pull requests on repositories that run privileged CI workflows

• Stores production credentials, API keys, or deploy tokens in GitHub Secrets

...has a version of this same risk in their environment. Open source companies, SaaS platforms, and any organization with a large GitHub presence should treat this incident as a direct prompt to audit their own workflows.

Our Technical Analysis

When we analyzed this attack pattern in our lab environment, the first thing we did was set up a test repository with a pull_request_target workflow to see exactly how the exploitation chain plays out. The results were eye-opening.

When we ran the scan against our test workflow, we noticed that the moment a forked PR triggered the workflow, the environment variables, including test tokens we had deliberately planted, were immediately accessible to any code running inside the CI job. There was no additional authentication step, no confirmation, no warning in the logs that elevated secrets were now exposed.

In our practical test, we noticed that deleting the fork post-attack actually does clean up most of the visible evidence in the GitHub interface. The workflow run logs persist, but without knowing what to look for, an organization without canary tokens or audit log monitoring would have very limited visibility into what happened during that CI run.

We encountered a challenge while testing containment scenarios: revoking a GitHub App token does not immediately invalidate all API calls in flight. There is a brief window, seconds to minutes depending on caching, where the token may still function. Grafana's team moved quickly, but in more complex attack scenarios, that window matters.

The takeaway from our testing: this class of vulnerability is genuinely dangerous, quietly present in many repositories, and harder to detect after the fact than most teams expect.

How to Prevent GitHub Token Theft and Pwn Request Attacks

Immediate Actions for GitHub Administrators

Audit your workflows right now:

• Search all repository workflows for pull_request_target trigger

• For each one, verify whether the workflow checks out or runs any code from the pull request

• If it does, this is a critical finding that needs immediate remediation

Restrict secret access:

• Review which secrets are accessible in which workflow contexts

• External forks should never have access to production secrets

• Use environment-level secret scoping rather than repository-level where possible

Canary Token Deployment : Grafana's Key Lesson

Grafana detected this attack because they had canary tokens deployed. You can do this too. Tools like Canarytokens.org allow you to generate fake credentials that alert you when used.

Deploy canary tokens:

• As fake API keys in dummy configuration files

• Inside source code repositories as comments or placeholder values

• In environment variable configurations that look real but trigger alerts when accessed

CI/CD Pipeline Hardening Checklist

• mcLmceast-privilege access for all GitHub Actions tokens - request only necessary scopes

• Secret scanning enabled - GitHub's built-in secret scanning catches accidentally committed credentials

• Branch protection rules on all default and release branches

• Audit logs monitored - set alerts for unusual API activity or access patterns

• OIDC token authentication - use short-lived identity tokens instead of static API keys

• Workflow pinning - pin all third-party GitHub Actions to a specific commit SHA, not a version tag

• Review pull_request_target usage - audit every workflow using this trigger across all repositories

• Token rotation schedule -ltw implement automatic rotation for all long-lived credentials

Grafana Labs Security Breach: Complete Incident Timeline

Date	Event
May 15, 2026	CoinbaseCartel initiates attack - fork created, malicious workflow triggered
May 15, 2026	Environment variables dumped, GitHub token extracted
May 15, 2026	Private codebase fully downloaded across multiple repositories
May 15, 2026	Fork deleted to remove evidence
May 15, 2026	Canary token triggered - Grafana global security team alerted
May 15–16, 2026	Forensic analysis begins - compromised credentials invalidated — vulnerable GitHub Action removed - all public repository workflows disabled
May 16, 2026	Public disclosure via official statement
May 16, 2026	Ransom demand issued by CoinbaseCartel - Grafana refuses
Ongoing	Investigation continues, additional security measures implemented, post-incident review to be shared

Frequently Asked Questions About the Grafana Labs Security Breach

What caused the Grafana Labs security breach?

The breach was caused by a "Pwn Request" vulnerability in a recently enabled GitHub Action. The workflow used a pull_request_target trigger, which allowed code from an external forked pull request to execute inside a trusted CI environment with access to privileged production secrets. The attacker injected malicious code through a forked repository, extracted a GitHub App token from the environment variables, and used it to download Grafana's private codebase.

Did hackers steal customer data from Grafana Labs?

No. Grafana's investigation confirmed that no customer data or personal information was accessed during the incident. There is no evidence of impact to customer systems or operations. The attack was focused on the internal codebase, not on customer-facing systems.

What is a Pwn Request vulnerability?

A Pwn Request is a security vulnerability that occurs when a GitHub Actions workflow uses the pull_request_target trigger and then runs code from the incoming pull request inside that privileged context. Because pull_request_target runs in the trusted base repository environment, it has access to repository secrets. If the workflow executes code from the forked PR, an attacker can run malicious code with access to those secrets. The name comes from "PR" (pull request) + "pwn" (to compromise or take control).

Why are GitHub Actions risky?

GitHub Actions workflows often need access to sensitive credentials API keys, deploy tokens, cloud provider credentials to do their jobs. When workflows are misconfigured, those secrets can be exposed to untrusted code from external contributors. The pull_request_target trigger is one of the most common sources of this risk, but other misconfigurations like overly broad token permissions, unpinned third-party actions, and inadequate secret scoping also create significant exposure.

Did Grafana Labs pay the ransom demand?

No. Grafana Labs refused to pay the ransom, citing FBI guidance that paying ransoms does not guarantee data recovery and actively incentivizes future attacks. Instead, the company invalidated compromised credentials, removed the vulnerable GitHub Action, disabled workflows across public repositories, and published a detailed public disclosure.

How can companies secure CI/CD pipelines?

Key steps include: auditing all pull_request_target workflows, using OIDC token authentication instead of static credentials, pinning third-party GitHub Actions to specific commit SHA hashes, enabling GitHub's secret scanning, implementing least-privilege access for all workflow tokens, deploying canary tokens for early detection, and establishing regular automated audits of CI/CD configuration across all repositories.

What is CoinbaseCartel?

CoinbaseCartel is a data extortion cybercrime group that emerged in September 2025. They are assessed to be connected to the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems. Unlike traditional ransomware groups, they do not encrypt victim data. Instead, they steal data and threaten to publish it unless a ransom is paid. They have claimed over 170 victims across technology, healthcare, transportation, manufacturing, and finance sectors, and reached Bitdefender's Top 10 Ransomware Groups list within their first few months of operation.

Why are software supply chain attacks increasing?

Attackers have learned that targeting developer infrastructure and CI/CD pipelines gives them leverage over far more organizations than attacking any individual target directly. A successful attack on a widely trusted open source project, a popular package manager, or a shared build system can create downstream effects across thousands of dependent organizations.

Combined with the growing complexity of modern software supply chains and the volume of third-party components most applications include, this attack surface has expanded significantly while defensive investment has not kept pace.

Key Takeaways from the Grafana Labs Breach

The Grafana Labs security breach is a clear signal of where attacks are heading in 2026.

Five things stand out:

• CI/CD pipelines are now primary attack surfaces. The era of defending only the application is over. How you build software is as important to secure as what you build.

• The Pwn Request vulnerability is widespread. Thousands of repositories use pull_request_target workflows incorrectly. Many have not audited this risk.

• Canary tokens work. Grafana detected this attack because they had extensive tripwire infrastructure deployed. Without it, the breach might have gone undetected for weeks or months.

• Refusing to pay ransom is the right call. It is also a harder call than it sounds when your codebase is the leverage. Grafana made the right decision.

• Transparency builds trust. Grafana's rapid public disclosure - on the same day as the ransom demand, sets a standard that more companies should follow.

The growing threat of software supply chain attacks demands that development teams think like security teams. Every workflow, every credential, every third-party action is an entry point. The question is not whether your organization has this class of vulnerability the question is whether you know where it is before an attacker finds it first.

Recommended next step: Search your organization's GitHub repositories for pull_request_target workflows today. Verify whether any of those workflows check out or execute pull request code. If they do, remediate immediately. Do not wait for your own canary token to fire.