Trivy Security Scanner Compromised in Supply Chain Attack

On March 19, 2026, security researchers confirmed that Trivy, one of the most widely used open-source container security scanners, had been compromised in a supply chain attack. The group responsible, identified as TeamPCP, used access to Trivy’s build pipeline to plant malicious code that would later be used to reach other targets. Most notably, it became the initial vector for the LiteLLM compromise five days later.

What Is Trivy?

Trivy, maintained by Aqua Security, is an open-source vulnerability scanner for container images, filesystems, and Git repositories. It’s one of the default tools in many CI/CD pipelines for checking containers before they’re deployed. The tool has millions of downloads and is embedded in hundreds of security workflows, including automated scanning in GitHub Actions, GitLab CI, and Jenkins.

That adoption is exactly what made it a target.

How the Compromise Worked

TeamPCP gained access to the Trivy build and publishing pipeline, the specific attack vector is still under investigation, but early reports point to a compromised maintainer credential used to push to the project’s CI system. From there, they injected code into Trivy’s release artifacts that could exfiltrate environment variables and credentials from machines running the scanner.

The malicious payload was subtle enough to avoid immediate detection. Trivy runs with elevated access in most pipelines because it needs to scan container layers and read system files. An attacker who compromises a tool with that level of access can read essentially anything in the CI/CD environment: API tokens, cloud credentials, signing keys, database passwords.

Security tools are high-value targets precisely because they’re trusted. When a developer installs a security scanner, they’re not thinking about auditing it the way they might audit an unknown library. The trust model works against users here.

Why Compromising Security Tools Is Especially Dangerous

Most malicious packages in the npm or PyPI ecosystems require that a developer actively install them. A social engineering attack might trick someone into adding a malicious dependency. But compromising a security tool is different for two reasons.

First, security tools occupy the top of the trust hierarchy in a development pipeline. If Trivy says something is safe, developers believe it. Introducing malicious behavior into that tool undermines the entire scanning process at the same time it enables credential theft.

Second, security tools run with broad permissions. A container scanner needs access to container layers, environment variables, mounted secrets, and often cloud provider credentials to function. That access profile is nearly identical to what an attacker wants.

The combination, high trust, broad access, makes this category of compromise far more dangerous than a typical malicious package.

The LiteLLM Connection

The Trivy compromise was not an end in itself. TeamPCP used credentials exfiltrated through the malicious Trivy build to access LiteLLM’s infrastructure. Specifically, they obtained PyPI publishing tokens that allowed them to push malicious versions of LiteLLM to the Python Package Index five days later on March 24.

That attack is covered separately, but the Trivy compromise is important to understand on its own terms. It demonstrates a pattern: attackers are no longer just going after end-user applications. They’re targeting the tools that build, test, and secure those applications, one step back in the chain, where trust is highest and scrutiny is lowest.

What to Do Now

If your CI/CD pipeline runs Trivy, you should:

1. Pin to a known-good version. Check the Trivy security advisory for the affected version range and ensure you’re running a clean release. The Aqua Security team has published guidance on which releases are affected.
2. Rotate credentials. If Trivy ran in any environment between the affected dates, assume any credentials in that environment were potentially exposed. Rotate API tokens, cloud provider keys, and signing credentials.
3. Audit your pipeline. Review what secrets are accessible in the environment where Trivy runs. Limit exposure using scoped credentials and environment isolation where possible.
4. Monitor for unusual activity. Check cloud provider logs and access logs for unexpected activity in the week following the compromise window.

The broader lesson here is about the trust model for security tooling. The same scrutiny you’d apply to a new dependency should apply to new versions of tools that run with elevated access in your pipeline. Version pinning and automated alerts for dependency updates are not optional hygiene, they’re how you find out when something like this happens before it’s too late. Dependabot for dependency security is the free way to get those alerts on a GitHub repository.