In March 2026, a threat actor known as TeamPCP executed one of the most consequential open source supply chain attacks on record. Starting with a compromised security scanning tool, they cascaded across five package ecosystems in under two weeks, ultimately poisoning LiteLLM, a Python package managing AI API credentials for organizations that include LiteLLM customers such as NASA, Netflix, Stripe, and NVIDIA. The attack didn’t require a developer to do anything wrong. A dependency of a dependency of a plugin was enough. This article examines what happened, why the traditional “scan and pray” model failed, and what a more defensible approach to open source looks like.
Key Takeaways
- TeamPCP compromised Trivy, a widely used security scanner, on March 19, 2026, then used stolen CI credentials to cascade into Checkmarx GitHub Actions, LiteLLM, Docker Hub, npm, and Open VSX, five ecosystems in two weeks.
- The LiteLLM attack targeted a package with 97 million monthly downloads whose sole function is aggregating AI API credentials, making it a single point of total credential compromise.
- The malicious payload executed automatically on package installation with no import required, bypassing standard code review and dependency scanning.
- Traditional scanning tools failed because the malicious code was injected at the source into trusted, verified actions, not into unknown or suspicious packages.
- Building open source from source, pinning dependencies to verified commit SHAs, and enforcing continuous remediation SLAs are the structural changes that reduce exposure to this class of attack.
The Attack Nobody Saw Coming, Until a Developer’s Machine Started Dying
On March 19, 2026, TeamPCP compromised Trivy, Aqua Security’s widely used open source vulnerability scanner. That breach was assigned CVE-2026-33634 with a CVSS score of 9.4. But Trivy was never the target. It was the key.
The credentials stolen from Trivy’s CI pipeline were used to poison Checkmarx’s GitHub Actions workflows four days later. Those compromises harvested more tokens. Those tokens unlocked more repositories. Within two weeks, TeamPCP had moved through five separate package ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI.
The final, most damaging payload landed in LiteLLM, a Python library with 97 million monthly downloads whose entire function is routing AI API credentials, OpenAI, Anthropic, Google, Amazon, and others, through a single proxy. The attacker didn’t need to find your credentials. You had already consolidated them in one place. They just needed to own the package.
What stopped widespread, undetected exfiltration wasn’t a scanner, an alert, or a security tool. It was poor operational security in the form of poor operational security in the form of poorly written code. The malware consumed so much RAM that a developer noticed their machine slowing down, investigated, and found a package they hadn’t knowingly installed. It had been pulled in as a dependency of a Cursor MCP plugin.
TeamPCP posted on Telegram shortly after: “Many of your favourite security tools and open-source projects will be targeted in the months to come.”
They are not finished.
Why Your Current Stack Didn’t Catch This, and Won’t Next Time
The Sysdig researchers who analyzed the Checkmarx compromise said it plainly: “Code review and dependency scanning failed here because the malicious code was injected into a trusted action at the source.”
This is the fundamental problem with the scan-first model. Scanners assess what’s already in your environment. They tell you the house is on fire. They don’t prevent the fire.
When a trusted package maintainer account is compromised, or when credentials stolen from one tool are weaponized to poison another, the binary you’re pulling looks legitimate. It came from the right repository, published by the right account, under the right version tag. The tag itself was force-pushed to a malicious commit. No scanner catches that at the point of installation.
The broader attack chain also exposes a problem most security leaders underestimate: transitive dependency blindness. Nobody chose to install LiteLLM on that compromised developer’s machine. It arrived as a dependency of a dependency of a plugin. At that depth, visibility collapses. Most organizations have no idea what’s actually running three or four levels below their direct dependencies, let alone whether those components were built from verified source.
A More Defensible Posture: What Actually Changes the Outcome
The TeamPCP attacks weren’t sophisticated in the traditional sense. They were methodical. They exploited the trust assumptions baked into how the open source ecosystem distributes software, and they cascaded because each breach produced credentials that funded the next one.
Structural defense against this class of attack requires moving upstream of the binary.
Build from source, or know who did. Pre-built binaries require blind trust in the build environment they came from. When that environment is compromised, as Trivy’s was, everything downstream inherits the compromise. Building from source within a hermetically sealed, SLSA Level 3 compliant infrastructure eliminates that inherited risk. You control the ingredients, not just the label.
Pin to verified commit SHAs, not version tags. Tags can be force-pushed. This is not a hypothetical; it is exactly how TeamPCP executed the Trivy and Checkmarx attacks. Pinning GitHub Actions and dependencies to full commit SHAs is a concrete, immediate change that removes this attack vector.
Treat transitive and OS-level dependencies as first-class citizens. The package your developer installed is not the risk. The forty dependencies it pulled with it are. Full visibility into transitive dependencies, including OS-level libraries, is the only way to understand your actual attack surface. According to the ActiveState State of Vulnerability Management and Remediation Report, 91% of DevSecOps leaders report limited visibility into container components as their biggest blind spot. That gap is where TeamPCP lived.
Enforce remediation SLAs, not just detection SLAs. Industry average time to remediate a critical CVE runs upward of 63 days, while attackers take just 5-7 days to take advantage of CVEs. That is not a scanning problem; it is a remediation infrastructure problem. Organizations that close critical vulnerabilities in 5 business days, highs in 10, and all others in 30, operate at a structurally different risk level than those waiting on upstream patches.
Curate what enters your environment before it gets there. Developers shouldn’t be pulling from the open internet, and increasingly, AI coding tools are pulling on their behalf. A private, vetted catalog of pre-approved components, accessible through the tools your developers already use, like pip, without changing their workflow, is how you enforce policy without creating friction that developers route around.
The AI Accelerant Nobody Planned For
The LiteLLM attack is a preview, not an anomaly.
Every AI coding assistant, every internal copilot, every agent your team deployed this year runs on hundreds of packages. Most of those packages were never explicitly chosen. They arrived as transitive dependencies. Your attack surface is not the code your developers wrote. It is the entire supply chain underneath what their AI tools generated.
As JFrog’s CEO put it: “Code agents are not going to sleep. They are not going to eat. They are not taking PTOs. They just create more and more source code. This tsunami of binaries, where will it land?”
The answer, right now, is in environments that have far less visibility than the speed of their AI adoption requires.
Conclusion: The Risk Is Not Going Away. Your Security Posture Can
TeamPCP is not done. They said so publicly. And the structural vulnerabilities they exploited, blind trust in pre-built binaries, cascading CI credential exposure, transitive dependency blindness, are not unique to the tools they targeted. They are endemic to how most organizations consume open source today.
The question for every security leader right now is not whether this class of attack will hit their environment. It is whether their current posture would catch it before a developer’s overworked laptop did.
ActiveState was built to close this gap. Our library of 79 million open source components, built from source within SLSA Level 3 infrastructure, with full provenance, continuous remediation, and native integration into your existing CI/CD pipelines and AI coding tools, is the structural answer to a structural problem.
If the TeamPCP attacks changed how you’re thinking about your open source posture, we should talk.
Contact our team to see how ActiveState can reduce your open source risk without slowing your developers down.
Frequently Asked Questions
TeamPCP is a threat actor that in March 2026 executed a cascading supply chain attack beginning with the compromise of Trivy, an open source vulnerability scanner. Using credentials stolen from Trivy's CI pipeline, they poisoned tools and packages across five ecosystems including GitHub Actions, Docker Hub, npm, Open VSX, and PyPI, culminating in the compromise of LiteLLM, a Python package used to manage AI API credentials by organizations including NASA, Netflix, Stripe, and NVIDIA.
Because the malicious code was injected at the source into trusted, verified packages. Scanning tools assess what is already in your environment against known vulnerability databases. When a trusted maintainer account or CI system is compromised and malicious code is published under a legitimate version, it arrives looking like a valid, expected artifact. Sysdig confirmed: dependency scanning failed because the attack happened upstream of the scan.
Building from source means compiling open source components directly from their original code within a controlled, verified build environment rather than consuming pre-built binaries from upstream providers. Pre-built binaries require you to trust that the environment that produced them was not compromised. Building from source within a SLSA Level 3 compliant infrastructure gives you cryptographic proof of how each component was built and eliminates inherited risk from compromised upstream build systems.
Transitive dependencies are packages that your direct dependencies depend on. When you install one package, you often inherit dozens of additional packages you never explicitly chose. The LiteLLM attack reached compromised machines because it was pulled in as a transitive dependency of a plugin, not a direct install. Without full visibility into transitive and OS-level dependencies, your actual attack surface is significantly larger than your known dependency list.
The most effective structural changes include: pinning GitHub Actions and dependencies to full commit SHAs rather than mutable version tags; building or sourcing open source from verified, build-from-source infrastructure; maintaining a curated catalog of pre-approved components that developers access through existing tooling; enforcing aggressive remediation SLAs for critical CVEs; and achieving full visibility into transitive and OS-level dependencies across all environments.
ActiveState provides a library of 79 million open source components built from source within SLSA Level 3 compliant infrastructure, with full build-time provenance for every artifact. Components are continuously monitored and remediated according to industry-leading SLAs, 5 business days for critical CVEs. Curated catalogs allow security teams to control exactly which components enter their environment, accessible through existing tools like pip with no workflow disruption. This eliminates the blind trust in pre-built binaries that the TeamPCP attacks exploited.
