Databricks is investigating an alleged TeamPCP-related compromise, but no confirmed breach is public yet

Databricks is reportedly investigating whether its platform was affected by the wider TeamPCP supply chain campaign, but no public evidence currently confirms a Databricks compromise. The claim appears to trace to threat-intelligence reporting amplified on social media, while Databricks has not published a public incident statement or advisory that confirms impact as of March 30, 2026.

That distinction matters. TeamPCP is a real and active supply chain threat, and several vendors have already confirmed compromises in adjacent ecosystems. But the Databricks angle remains an allegation under investigation, not a verified intrusion with publicly released forensic findings.

So the responsible framing is this: organizations that integrate Databricks into CI/CD or cloud automation workflows should stay alert, but they should not treat Databricks as a confirmed victim unless Databricks or another primary source publishes evidence.

What is confirmed about TeamPCP

TeamPCP has already been tied to a broad supply chain campaign that hit widely used developer and security tooling. Confirmed public reporting names compromises or malicious tampering affecting Aqua Security’s Trivy ecosystem, related GitHub Actions, Checkmarx-linked assets, LiteLLM, and other package or automation paths across npm, PyPI, Docker, and GitHub workflows.

Aqua Security said on March 19, 2026 that attackers used compromised credentials to publish malicious Trivy releases and tamper with trivy-action and setup-trivy, and it advised users to rotate secrets exposed to affected CI/CD environments. GitHub later published a security advisory confirming malicious tag changes and compromised action references.

Researchers from Aikido, Wiz, Arctic Wolf, ReversingLabs, and others have also documented the campaign’s spread and evolution, including credential theft from build pipelines, fallback command infrastructure, and follow-on compromises across additional ecosystems.

🚨‼️ BREAKING: Databricks allegedly compromised in a TeamPCP supply chain attack.

Databricks is the leading cloud-based data analytics platform: used by organizations worldwide to manage massive datasets.

We notified them last week. They scaled up to investigate. We haven't… pic.twitter.com/ncRjecLOjJ

— International Cyber Digest (@IntCyberDigest) March 30, 2026

What is confirmed vs. what is still unconfirmed

Topic	Status
TeamPCP supply chain campaign exists	Confirmed by multiple security firms and public advisories
Trivy and related GitHub Actions compromise	Confirmed
Broader spread across open-source ecosystems	Confirmed
Databricks currently investigating possible impact	Reported
Databricks compromise confirmed by Databricks	Not publicly confirmed

Why Databricks entered the conversation

The current Databricks claim appears in a recent SANS Internet Storm Center campaign update, which described Databricks as investigating an alleged compromise linked to TeamPCP credential harvesting. That language itself is cautious and does not say Databricks was definitively breached.

Separately, International Cyber Digest posted that Databricks was allegedly compromised, and some secondary articles repeated that claim. At the same time, I did not find a Databricks press release, security advisory, or status post confirming a breach or describing affected customers.

That leaves the story in a familiar but important middle ground. The allegation is credible enough to investigate because TeamPCP has already compromised major supply chain targets. Still, the public record does not yet support a headline that states Databricks was compromised as fact.

Why this matters even without a confirmed Databricks breach

Databricks runs in many high-value enterprise data and AI environments, so even an unconfirmed investigation deserves attention. If a supply chain actor accessed build secrets, cloud tokens, or automation credentials connected to a Databricks deployment, the downstream impact could include workspace access, data exposure, or abuse of connected cloud services. This is an inference from how TeamPCP has operated elsewhere, not a confirmed Databricks-specific outcome.

The timing also makes the story more visible. Databricks launched Lakewatch, its new open, agentic SIEM product, on March 24, 2026, just days before the new allegation circulated. That launch has no evidence-based connection to the TeamPCP claim, but it explains why Databricks drew extra attention in security coverage this week.

In other words, this is a case where defenders should stay practical. Separate the confirmed TeamPCP campaign from the still-unconfirmed Databricks claim, then respond based on your own exposure to known affected tools and secrets.

What organizations should do now

If your environment used confirmed TeamPCP-affected components such as Trivy-related GitHub Actions or other recently compromised supply chain assets, rotate any secrets that those pipelines could access. That advice comes directly from confirmed incident reporting and does not depend on whether Databricks was affected.

Teams that connect Databricks to CI/CD, GitHub Actions, cloud automation, or shared service principals should review recent credential use, service principal activity, and unusual token creation or reuse. This is a prudent defensive step based on the campaign’s known focus on stolen CI/CD and cloud secrets.

Security teams should also watch for an official Databricks statement. Right now, the absence of a public advisory is a key part of the story, and that could change quickly if the investigation confirms or rules out impact.

Practical mitigation steps

• Rotate secrets exposed to affected CI/CD pipelines
• Audit GitHub Actions and package workflows for TeamPCP-linked indicators
• Review Databricks-connected service principals, tokens, and automation accounts
• Check cloud logs for unusual access after recent pipeline runs
• Monitor Databricks for any official advisory or customer communication

FAQ