What Happened
On May 11, 2026, Grafana Labs detected unauthorized access to multiple GitHub repositories containing source code and internal information. The entry point was a compromised TanStack npm package. The threat actor, TeamPCP, injected malicious code into the dependency, which Grafana's development environment executed. This allowed attackers to access GitHub tokens and clone repositories before Grafana could respond.
Five days later, on May 16, an extortion group called CoinbaseCartel contacted Grafana demanding payment. Grafana refused. The company rotated all exposed credentials, audited commits for backdoors, and disclosed the incident publicly.
Timeline
May 11, 2026: Grafana detects anomalous repository access patterns. Investigation reveals a compromised npm dependency.
May 11: Security team rotates all potentially exposed GitHub tokens and API keys. Engineering begins auditing all commits made during the exposure window.
May 16, 2026: CoinbaseCartel sends extortion demand via encrypted channel.
May 16-17, 2026: Leadership decides against payment. Legal and communications teams prepare disclosure.
Post-disclosure: Grafana publishes incident summary, confirming no customer data or production systems were accessed.
Which Controls Failed or Were Missing
Dependency Verification: Grafana's build pipeline executed the malicious TanStack package without detecting the injected code. This indicates missing or insufficient:
- Package integrity verification (checksum validation)
- Behavioral analysis of dependencies during installation
- Sandboxed build environments that limit token access
Token Scope and Rotation: The compromised tokens had sufficient privileges to read multiple repositories. The incident reveals:
- Overly broad token permissions
- No automatic token rotation schedule
- Tokens accessible to build processes that didn't need repository access
Supply Chain Monitoring: The malicious package was present in Grafana's environment long enough for TeamPCP to identify valuable targets and exfiltrate data. Missing capabilities:
- Real-time dependency monitoring for known-malicious packages
- Alerting on new network connections from build processes
- Automated rollback when supply chain compromises are disclosed publicly
What the Relevant Standard Requires
The NIST Cybersecurity Framework addresses supply chain risk in the "Identify" function:
- ID.SC-01: Maintain an accurate inventory of suppliers and third-party service providers
- ID.SC-02: Maintain an inventory of the organization's suppliers' cybersecurity practices
- ID.SC-04: Maintain contracts with suppliers and third-party partners that include cybersecurity requirements
Your npm dependencies are suppliers. Each package is a third party with access to your build environment.
ISO/IEC 27001:2022 Control 5.19 requires:
- Define and document information security requirements for supplier relationships
- Monitor supplier service delivery and review for compliance
- Manage changes to supplier services
NIST 800-53 Rev 5 specifies SR-3 (Supply Chain Controls and Processes):
- Employ integrity verification mechanisms to detect unauthorized changes to software and firmware
- Limit access to software based on the principles of least privilege
The GitHub token that TeamPCP stole violated least privilege. Build processes that install dependencies don't need read access to your entire repository catalog.
PCI DSS v4.0.1 Requirement 6.3.2 states: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
If you're handling cardholder data, you must know what's in your dependency tree, including every transitive dependency that can execute code in your environment.
Lessons and Action Items for Your Team
Lock Your Dependency Versions with Cryptographic Hashes. Don't trust semantic versioning alone. In your package-lock.json or equivalent, every dependency should have an integrity hash. When TanStack's maintainers published the compromised version, anyone using ^ or ~ version ranges pulled it automatically. Hash-pinned dependencies would have rejected it.
"dependencies": {
"@tanstack/react-query": {
"version": "5.x.x",
"integrity": "sha512-abc123...",
"requires": { ... }
}
}
Sandbox Your Build Environment. Your CI/CD pipeline should run in a container or VM with:
- No access to production credentials
- Network egress limited to package registries and your artifact store
- Read-only filesystem except for designated build output directories
- Separate service accounts with minimal GitHub permissions
If a dependency tries to exfiltrate data, it hits a wall.
Rotate Tokens on a Schedule, Not Just After Incidents. Grafana rotated everything on May 11—good. But why did those tokens exist without an expiration date? Implement:
- 90-day maximum lifetime for all API tokens
- Automated rotation with secret management tools (Vault, AWS Secrets Manager)
- Monitoring for tokens that haven't rotated on schedule
Monitor Your Dependencies in Real Time. Tools like Socket.dev, Snyk, or GitHub's Dependency Graph can alert you when:
- A package you use gets flagged for malicious behavior
- A new version introduces unexpected network calls or filesystem access
- Your dependency tree pulls in a new transitive dependency
Grafana learned about the TanStack compromise from behavioral anomalies in their GitHub logs. You want to know before the attacker finds something worth stealing.
Decide Your Extortion Response Policy Now. Grafana refused to pay CoinbaseCartel. That's the right call for most organizations—paying funds criminal infrastructure and guarantees nothing. But make this decision in a conference room, not during an active incident. Document:
- Who has authority to negotiate or refuse
- What data exposure would change the calculus (customer PII, payment data, HIPAA-covered records)
- How you'll communicate the decision to affected parties
Audit Commits During the Exposure Window. Grafana's security team reviewed every commit made while the malicious package was active. You should have a runbook for:
- Identifying all code changes during a compromise window
- Searching for backdoors, credential leaks, or logic bombs
- Re-reviewing merged pull requests with fresh eyes
Attackers don't always smash and grab. Sometimes they plant persistence mechanisms for later use.
Test Your Incident Response Plan Against Supply Chain Scenarios. Most tabletop exercises focus on phishing or ransomware. Add a supply chain breach to your rotation:
- "Your logging library starts sending data to an unknown IP. What do you do first?"
- "A developer's npm account was compromised. Which systems are at risk?"
- "How quickly can you rebuild your application without any third-party dependencies?"
The Grafana breach proves that your dependencies are as much a part of your attack surface as your own code. Treat them accordingly.
