In this article​
Summary
In March 2026, a threat group called TeamPCP compromised Trivy, a widely trusted security scanner, and used it to backdoor LiteLLM, an AI gateway installed across millions of developer environments. The attack has been assigned CVE-2026-33634 with a severity score of 9.4 out of 10. This article explains what happened, why it matters for every organization running software pipelines, and what you can do now.
What happened with the CVE-2026-33634 supply chain breach?
Most cyberattacks target something obviously valuable: a database, a login page, a payment system. The TeamPCP attack that unfolded across March 2026 took a different approach. It targeted the tools organizations use to protect themselves, and that is exactly what made it so effective.
The attackers did not break into a product or steal customer data directly. They compromised Trivy, a widely used open source security scanner maintained by Aqua Security. Once inside Trivy, they could reach everything that used Trivy to check its own code. That included LiteLLM, an AI gateway widely embedded across cloud environments, whose breach exposed credentials across tens of thousands of developer systems worldwide. The same campaign also hit Checkmarx’s KICS and components across the npm and Docker ecosystems.
The incident has been assigned CVE-2026-33634, with a CVSS severity score of 9.4 out of 10. This is what a modern supply chain attack looks like. Let’s break down what it means in non-technical language.
How the TeamPCP infostealer compromised Trivy and CI/CD pipelines
Imagine a health inspector visiting restaurants in a city. Everyone trusts the inspector. Restaurants unlock their kitchens, show their storage areas, and share their supplier lists. Now imagine an attacker impersonating that inspector. Suddenly, they have access to every kitchen in town.
Trivy was that inspector. Thousands of software teams use it to scan their code for problems. When the attackers published a poisoned version of Trivy (v0.69.4) to official distribution channels, including GitHub Releases and container registries, those teams unwittingly invited it into their build pipelines; the automated systems that compile, test, and publish their software. From inside those pipelines, the fake Trivy extracted passwords, access keys, and API credentials, then sent them back to the attackers.
The credentials it stole from LiteLLM’s pipeline were then used to publish two backdoored versions of LiteLLM itself on PyPI, the public library where millions of developers download Python packages. Those two versions, 1.82.7 and 1.82.8, were live for around two to three hours before being pulled. This is long enough.
Three attack vectors were in play across the broader campaign, and all three are common in modern software delivery:
- Compromised packages published to public repositories
- Unpinned GitHub Actions: automated workflow scripts that run on a floating tag rather than a fixed version, meaning attackers can silently change what they point to.
- Mutable Docker image tags: container images that can be swapped out without the teams using them noticing
Why LiteLLM made such a valuable target
LiteLLM is not a general-purpose library. It is a gateway specifically designed to hold API keys for AI providers: OpenAI, Anthropic, Google, and dozens more. Its entire purpose is to sit at the center of an organization’s AI infrastructure and manage access to language models. That makes it a uniquely high-value target: compromise LiteLLM, and you don’t just get a key, you get the entire keyring.
As organizations build more AI into their pipelines, automated testing, code generation, agentic workflows, those pipelines become richer targets. They hold more credentials, they run with more permissions, and they are trusted to act autonomously. An attacker who gets into that layer does not need to trick a human. The automation does the work for them.
The governance gap the TeamPCP attack exposed
The Trivy and LiteLLM incident is more about trust than it is about sophisticated attackers.
Every organization that used Trivy trusted it implicitly. That trust was reasonable. Trivy is a legitimate, well-maintained project. But “legitimate” and “currently uncompromised” are not the same thing. The teams whose pipelines pulled the poisoned Trivy binary had no automatic way to know something had changed. Their pipelines ran. Their scans completed. Everything looked normal.
This is a pattern Software Improvement Group (SIG) sees repeatedly when analyzing software portfolios. The gap between what an organization believes is running in its systems and what is actually there is where risk accumulates. Software portfolios, and the pipelines that build them, grow faster than the governance structures around them. That gap is where TeamPCP operated.
The organizations that responded fastest to CVE-2026-33634 were the ones who already knew what was in their pipelines. They could immediately check whether they had installed the affected versions, assess what credentials might have been exposed, and act. The organizations without that visibility had to start from scratch, under time pressure, with credentials potentially already in attacker hands.
More disclosures from this campaign are expected in the coming days. The exposure window is still open.
What to do now if you use Trivy or LiteLLM
The immediate actions are concrete. If your organization runs software pipelines, these three checks are worth doing immediately:
1. Check for vulnerable LiteLLM versions.
Versions 1.82.7 and 1.82.8, installed between March 24, 2026 at 10:39 UTC and 16:00 UTC, are confirmed compromised. Any credentials present in that environment during that window should be considered exposed and rotated.
Audit your GitHub Actions for unpinned dependencies.
Workflows that call external actions using a tag like @v1 or @latest rather than a full commit reference can be silently redirected. Pinning to a specific commit SHA removes that risk.
3. Check your Docker base images.
Images using floating tags like latest can be swapped out without detection. Pinning to an immutable digest, for example FROM alpine:3.21@sha256:…, ensures what runs is what you verified.
How Software Improvement Group can help
Continuous visibility into what is running in your software portfolio is the foundation of responding well when incidents like CVE-2026-33634 happen.
Sigrid®’s Open-Source Health capability gives you that view, across vulnerabilities, dependency freshness, and license risk.It monitors your software as it changes rather than producing a one-time snapshot, with vulnerability data updated within days as new risks are published.
If you want to understand your organization’s exposure, whether that means a focused review of your pipelines, a check on whether any of your projects use affected components, or a broader view of your open-source dependencies, please reach out to us directly.
About the author
Werner Heijstek
Werner Heijstek is the Senior Director at Software Improvement Group and host of the SIGNAL podcast, a monthly show where we turn complex IT topics into business clarity.