CVE-2026-33634: Responding to the Trivy and LiteLLM Supply Chain Attacks

Update, April 1, 2026: TeamPCP's campaign continues to expand. New downstream compromises are being reported. This post will be updated as the situation develops. The guidance below reflects what is confirmed as of publication.

On March 19, 2026, threat actor TeamPCP compromised Aqua Security’s Trivy vulnerability scanner, injecting credential-stealing malware into its official releases and GitHub Actions. Five days later, that compromise cascaded into LiteLLM, the Python library that gives developers a unified interface to call over 100 LLM providers. The campaign has now touched GitHub Actions, Docker Hub, PyPI, npm, and Open VSX. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog as CVE-2026-33634 with a CVSS score of 9.4.

This post explains what happened, what security and engineering teams should do now, and how to think about blast radius if you ran either tool during the exposure window.

What Happened: The Attack Unfolded in Stages

The attack did not begin with Trivy. It began weeks earlier, when a misconfigured GitHub Actions workflow allowed an automated bot to steal a privileged Personal Access Token from Aqua Security's CI environment. Aqua Security discovered the breach and rotated credentials, but the rotation was incomplete. TeamPCP retained access to residual credentials and waited.

On March 19, using those surviving credentials, TeamPCP force-pushed malicious commits to 76 of 77 version tags in the aquasecurity/trivy-action repository and all 7 tags in setup-trivy. They simultaneously published a backdoored Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases, Docker Hub, GHCR, and Amazon ECR.

The critical detail: the malicious tags and binary preserved all normal Trivy functionality. But while the scan was running, the malware was comprehensively searching the CI runner’s memory and filesystem for secrets. The secrets were then encrypted and exfiltrated to the typosquatted attacker-controlled domain scan.aquasecurtiy[.]org.

On March 23, the same campaign reached Checkmarx, compromising KICS GitHub Actions and two Open VSX extensions. The attacker-controlled domain checkmarx[.]zone was registered and used during this phase.

On March 24, LiteLLM's CI/CD pipeline ran Trivy as part of its standard build process, pulling from an official source without a pinned version. The compromised Trivy action exfiltrated LiteLLM's PyPI publish token from the GitHub Actions runner, as documented by Snyk. TeamPCP used that token to publish two backdoored versions of LiteLLM (1.82.7 and 1.82.8) directly to PyPI. Both versions were live for approximately six hours before removal.

The malware in the LiteLLM packages operated in three stages. The first stage executed the same comprehensive credential harvesting payload used in the Trivy compromise. The second stage focused on exfiltration via a similar mechanism used by the malicious Trivy GitHub Action. The encrypted payload was sent to the attacker-controlled domain models.litellm[.]cloud which had been registered the day before. The final stage focused on persistence and lateral movement via Python backdoors and a malicious systemd service that polls for new payloads. If a Kubernetes service account token was found in the first stage it attempts lateral movement by deploying a privileged pod to every node and deploying the same Python payload on the host filesystem.

Another detail worth noting, and one we have not seen widely covered elsewhere, the compromise can propagate through indirect action dependencies. If you use a GitHub Action that itself calls trivy-action or setup-trivy, your pipeline was exposed even if you never referenced Trivy directly. A wrapper action is enough.

How Large Is the Exposure

Trivy has nearly 33,000 GitHub stars and is the default scanner for Harbor, a RedHat-certified tool embedded across a significant share of enterprise CI/CD stacks. Many organizations run it not because they chose it deliberately but because it ships as a default in tools they already use.

LiteLLM has over 40,000 GitHub stars and approximately 97 million PyPI downloads in the last 30 days, roughly 3.6 million per day. Wiz reports it is present in 36% of cloud environments they monitor. Critically, LiteLLM is also a transitive dependency for a growing number of AI agent frameworks, MCP servers, and LLM orchestration tools. Many affected teams did not install it themselves. It arrived through something else they trusted.

At least 1,000 enterprise SaaS environments are estimated to have been affected at the time of writing. TeamPCP has publicly claimed to have harvested ~300GB of credential data.

Are You Affected: How to Check

For Trivy

Check whether any of your GitHub Actions workflows referenced the following during the exposure window:

• aquasecurity/trivy-action at any version tag (not SHA-pinned)
• aquasecurity/setup-trivy at any version tag (not SHA-pinned)
• Any action that wraps or calls either of the above

Also check developer machines for the presence of sysmon.py or a sysmon systemd service, and scan GitHub organization repositories for any tpcp-docs repositories, which indicate successful exfiltration.

For LiteLLM

You are potentially affected if any of the following are true:

• You ran pip install litellm between 10:39 UTC and 16:00 UTC on March 24, 2026, and received version 1.82.7 or 1.82.8
• You built a Docker image during that window with an unpinned LiteLLM dependency
• A dependency in your project pulled LiteLLM in as a transitive dependency during that window

You are not affected if you use the official LiteLLM Proxy Docker image, which pins dependencies in requirements.txt and did not pull the compromised packages.

Check your installed version:

pip show litellm

Check for the indicator of compromise:

find / -name "litellm_init.pth" 2>/dev/null

Note: simply uninstalling the affected versions is not sufficient. The litellm_init.pth file placed during installation continues to execute on every Python interpreter startup even after the package has been removed. If you ran the affected versions, you must explicitly check for and delete this file in addition to rotating credentials.

LiteLLM has published scripts to scan GitHub Actions job logs across your organization for jobs that installed the affected versions. Consult the LiteLLM security update for the current versions of those scripts.

What Can You Do Now

If You Were in the Exposure Window

Assume compromise. That is not alarmism, it is the right operational posture given what the malware was designed to collect.

Remove persistence. Remove persistence mechanisms before doing anything else. Check for and delete litellm_init.pth in your Python site-packages directory, the sysmon.service systemd unit, and ~/.config/sysmon/sysmon.py. Review Kubernetes clusters for privileged pods matching the node-setup-* pattern and remove them.

Rotate credentials immediately, starting with those that carry the highest risk of lateral movement. This includes cloud provider tokens (AWS, GCP, Azure), GitHub tokens and Actions secrets, PyPI publish tokens, SSH keys, Kubernetes secrets, API keys for LLM providers (OpenAI, Anthropic, and others stored in LiteLLM environments), and any database credentials accessible from affected environments. If there were credentials in the environment where the payload executed, assume they’ve been compromised.

Look for signs of pivot. Audit outbound connections from affected systems for traffic to models.litellm[.]cloud (an attacker-registered domain, not LiteLLM's infrastructure), checkmarx[.]zone (a TLD impersonation of Checkmarx), or scan.aquasecurtiy[.]org (note the typo in the domain, which is intentional). Review logs for any activity on credentials during the window before rotation.

‍Audit your action dependencies for indirect exposure. Do not limit your review to workflows that explicitly reference Trivy. Check every action your pipelines call and trace whether any of them wrap trivy-action or setup-trivy.

Regardless of Exposure

Pin GitHub Actions to SHA hashes, not version tags. This is the fix for the structural issue this attack exploited. A version tag like @v0.28.0 is mutable. A SHA reference is not. This change should be made across all workflows now, not just for Trivy-related actions.

Scope and shorten credentials. The credential hygiene failures that made this incident worse than it had to be are consistent: long-lived credentials with broad access stored as environment variables in CI pipelines. The remediation is to use short-term credentials wherever possible, scope them to the minimum required permissions, and where the platform supports it, bind them to specific IP ranges or machine identities so a stolen credential cannot be used from an attacker's infrastructure.

Pinning package versions is necessary but not sufficient. When a maintainer account is compromised, an attacker can publish a malicious version that carries valid signatures and passes hash verification. That is what happened here. The additional layer is to verify the integrity of packages against known-good checksums before the exposure window, use dependency lockfiles that were committed before the incident date, and treat any package installed or updated during a suspicious time window as potentially compromised regardless of its version number. This applies across ecosystems, npm, PyPI, RubyGems, and others.

Review outbound connectivity from CI runners. The malware succeeded in part because GitHub-hosted runners allow arbitrary outbound connections. Organizations running self-hosted runners have more control here and should implement network-level controls allowing only the necessary access. For GitHub-hosted runners, EDR tooling that flags unexpected outbound connections from build environments is the available mitigation.

The Structural Issue This Incident Exposes

Supply chain attacks target trust, not weakness. Trivy is a well-maintained, widely respected project. LiteLLM is a widely adopted and actively developed library. The attack worked not because these tools are poor quality but because they are trusted implicitly by the pipelines that use them, and that trust is rarely scrutinized at runtime.

Security tools in CI/CD pipelines run with elevated privileges by design. They need broad read access to find what they look for. That is the job. But it also means a compromised scanner has a categorically different blast radius than a compromised application. The scanner has access to everything the scanner needs to see, and in a CI environment, that is most of the secrets worth stealing.

The CI/CD security posture most organizations have today was not designed for a threat model where the scanner itself is the attack vector. Version-tagged actions, unpinned package installs, long-lived credentials stored as environment variables: these are normal, widespread practices that became liabilities the moment a trusted tool was weaponized.

The harder question this incident raises is not "how do we prevent the next Trivy." It is "if a trusted tool in our pipeline were compromised tomorrow, how quickly could we determine what an attacker had access to, where they could go next, and whether they already have?"

Understanding Your Blast Radius

When a credential theft incident like this one hits, most security teams work through three questions in sequence. The first is whether they were affected at all: checking CI logs, auditing which jobs ran during the exposure window, and confirming whether any of the compromised versions touched their environment.

The second is credential rotation: identifying everything that was in scope and rotating it, starting with the credentials that carry the highest risk of lateral movement.

The third question is the hardest, and the one most teams answer last: could the attackers have done anything with those credentials before rotation? Cloud provider tokens, Kubernetes secrets, and service account keys each carry different levels of access. Knowing which ones were exposed tells you what to rotate. Knowing what they could reach tells you whether you contained the incident or just closed one door. 

Most teams reconstruct that answer manually from their logs and whatever their SIEM captured. That process is slow and often incomplete under pressure.

If your team is still working through that third question, talk to us. Averlon maps what stolen credentials, such as AWS, GCP, and Azure tokens, have access to across your cloud environment so you can answer that question faster.

What to Monitor as This Campaign Continues

TeamPCP has not stopped. The campaign has already expanded from GitHub Actions to Docker Hub, PyPI, npm, and Open VSX. Each environment they compromise yields credentials that become the foothold for the next target. The pivot from CI/CD to production PyPI packages is a deliberate escalation of scope. Security researcher Rami McCarthy has been maintaining a comprehensive tracker of the campaign as it develops.

On March 27, the campaign reached the Telnyx SDK, with two malicious versions published to PyPI using a new delivery mechanism: malicious payloads embedded inside WAV audio files using steganography, a technique that bypasses tools that inspect only source code and binaries. The Cloud Security Alliance has published a comprehensive research note on the broader AI/ML supply chain campaign that this incident is part of.

On March 31, threat actors reportedly used credentials stolen through the Trivy compromise to breach Cisco's internal development environment, with source code and AWS credentials reported to have been stolen, and allegedly more than 300 GitHub repositories cloned.

We will continue to update this post as new developments emerge.