LiteLLM PyPI Compromise | Trivy Hack Exposed 2,500 Orgs

New analysis published this week puts hard numbers on one of 2026's messier build-pipeline compromises. Security firm CloudSEK says the LiteLLM PyPI compromise, which started with a poisoned Trivy GitHub Action back in March, touched more than 2,500 organizations and roughly 434,000 CI/CD pipeline runs. The two backdoored LiteLLM releases (1.82.7 and 1.82.8) were live on PyPI for only about 40 minutes on March 24, 2026, yet LiteLLM is an AI gateway that holds every model-provider key in an organization, which is exactly why the reach is worth taking seriously. The Hacker News reported on August 12 that CVE-2026-33634 now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components, and the story is back in circulation as researchers reconstruct how one unrevoked token cascaded through three separate tools.

This entry covers a supply chain attack that first broke on March 24. We are writing about it now because the scale estimate, the CVE update, and the detailed chain analysis all landed in the last few days. Treat the numbers as exposure, not confirmed breach: CloudSEK's figures measure how many pipelines and organizations sat on the affected path, not how many were actually compromised.

What happened

LiteLLM is an open-source AI gateway used to route requests across many model providers from a single API. It is popular. Cycode cited roughly 95 million monthly downloads from pypistats, and Sonatype put daily downloads near three million, so a compromised release has a very wide surface.

On March 24, 2026, a threat actor calling itself TeamPCP published two backdoored versions of the litellm package to PyPI. The malicious code was injected directly into the distributed wheels and functioned as a credential stealer and a dropper. According to Sonatype, there is speculation that TeamPCP is linked to LAPSUS$, but attribution remains under investigation.

The key detail is how the attacker got publish rights. They did not phish a maintainer directly. LiteLLM's continuous integration pipeline ran Aqua Security's Trivy scanner as a GitHub Action without pinning it to a verified version. A compromised Trivy release then ran inside LiteLLM's build environment and exfiltrated the PYPI_PUBLISH token from the GitHub Actions runner. With that token, the attacker uploaded the poisoned releases.

The accounts of exactly how the malicious packages reached PyPI differ. CloudSEK's report said the poisoned build produced and published the releases. LiteLLM's own incident report pointed to a direct upload that bypassed its official CI/CD workflow. Palo Alto Networks Unit 42 described attackers using stolen PyPI publishing tokens after the Trivy breach. Asked about the discrepancy, CloudSEK told The Hacker News the reports describe different stages of one attack chain rather than competing theories, with CloudSEK covering how the credential was obtained and the other two covering how it was used.

Timeline

The compromise was not a single event. It was a short campaign that walked from one CI tool into the next.

• March 19, 2026: Attackers rewrote Git tags in the Aqua Security trivy-action repository to point to a malicious release (v0.69.4) carrying credential-harvesting code, per Snyk. This is tracked as GHSA-69fq-xp46-6x23.
• March 23, 2026: Checkmarx's KICS GitHub Action was also reported compromised in the same wave, according to an incident write-up from FutureAGI. This detail appears in that single account, so treat it as reported rather than confirmed.
• March 24, 2026, ~10:39 UTC: Malicious LiteLLM 1.82.7 and 1.82.8 went live on PyPI.
• March 24, later that morning: Security researcher Callum McMahon (FutureSearch) opened GitHub issue #24512 after a fork-bomb side effect from the malicious loader crashed his development machine. Cycode reported that the attacker, still holding maintainer access, then tried to close the issue to suppress the discovery.
• March 24: PyPI quarantined the releases roughly 40 to 46 minutes after publication. LiteLLM's own advisory tells users to treat anything installed between 10:39 and 16:00 UTC as suspect, and Sonatype observed the versions available for at least two hours before full removal, so the exact exposure window varies by source.
• March 26, 2026: CVE-2026-33634 was added to CISA's Known Exploited Vulnerabilities catalog.
• April 2, 2026: PyPI published an incident report covering both litellm and telnyx, which was hit through the same Trivy token exposure.
• August 11 to 13, 2026: CloudSEK, Unit 42, and Snyk published detailed reconstructions, and the CVE record was updated to name the affected LiteLLM versions.

Who is affected

The last release known to be clean is 1.82.6. Only 1.82.7 and 1.82.8 carried the backdoor. The telnyx package was compromised through the same token exposure and is worth checking if you use it.

Per LiteLLM's advisory, you should assume exposure if any of the following are true. You ran pip install litellm or upgraded without pinning a version during the March 24 window and received 1.82.7 or 1.82.8. You built a Docker image in that window that included an unpinned pip install litellm. A dependency pulled LiteLLM in as an unpinned transitive dependency, for example through an AI agent framework, an MCP server, or an LLM orchestration tool.

You are most likely not affected if you ran the official LiteLLM Proxy Docker image, which pins dependencies in requirements.txt and did not resolve to the malicious PyPI wheels, or if you were pinned to 1.82.6 or earlier.

How the attack works

The payload used a nasty persistence trick. Alongside code in the wheel, the release dropped a .pth file named litellm_init.pth. Python executes .pth files as soon as the interpreter starts, so the malicious code ran on every Python invocation on the host, not only when an application imported LiteLLM. That is what caused the fork-bomb crash that led to discovery.

Once running, the code executed a three-stage operation. Stage one harvested credentials: SSH keys, cloud keys such as AWS, GitHub tokens, Kubernetes secrets, and crypto wallet material, with OX Security also noting Slack and Discord keys. Stage two attempted lateral movement across Kubernetes clusters. Stage three installed a persistent systemd backdoor that polled for additional payloads.

Stolen data was encrypted and exfiltrated over an HTTPS POST to models.litellm.cloud. LiteLLM confirmed that domain is not an official BerriAI or LiteLLM address. The single-sentence summary of the whole chain, as CloudSEK put it, is that one unrevoked token reached three tools deep, and that is what turned a single credential leak into ecosystem-wide exposure.

How to check if you are affected

First, confirm which version you actually have installed and whether the malicious loader exists on disk.

# Check the installed LiteLLM version
pip show litellm | grep -i version

# Hunt for the malicious loader file across the filesystem
find / -name "litellm_init.pth" 2>/dev/null

# List site-packages paths, then inspect them for stray .pth files
python -c "import site; print('\n'.join(site.getsitepackages()))"

Next, scan your dependency manifests and lockfiles for the two bad versions, including transitive resolutions.

grep -rniE "litellm==1\.82\.(7|8)|litellm.*1\.82\.(7|8)" \
  requirements*.txt poetry.lock Pipfile.lock uv.lock pdm.lock 2>/dev/null

Finally, look for signs the payload phoned home. Search host and proxy logs for the exfiltration domain.

grep -rni "models.litellm.cloud" /var/log . 2>/dev/null

If you have GitHub Actions logs from late March, check whether any workflow ran aquasecurity/trivy-action unpinned and whether secrets were referenced in the same job.

Remediation

If any check above hits, assume the host's secrets are burned and act on that basis.

1. Rotate every credential that was present on affected machines or reachable from them: cloud access keys, SSH keys, Kubernetes service-account tokens, GitHub tokens, LLM provider API keys, and any wallet keys. LiteLLM by design holds provider keys, so rotate those first.
2. Remove litellm_init.pth from every site-packages directory and delete any unexpected systemd unit that polls a remote host. Rebuild the machine if you cannot fully account for persistence.
3. Move off the bad versions. Do not stay on 1.82.7 or 1.82.8. Pin to a known-good release and let your resolver lock it.

pip install "litellm==1.82.6"   # last release before the compromise
# or move to a current, post-incident release and pin it in your lockfile

4. Pin GitHub Actions to full commit SHAs instead of moving tags. This is the root cause here: a mutable tag on a third-party action let a rewritten release run inside a trusted build. Snyk and the incident write-ups all point back to the unpinned Trivy action as the entry point.
5. Adopt PyPI Trusted Publishers for your own packages. Both LiteLLM and telnyx moved to Trusted Publishing after the incident, per PyPI's report, which removes long-lived publish tokens from CI runners.

FAQ

Is LiteLLM safe to use now?

Yes, current releases are clean. Only versions 1.82.7 and 1.82.8, published on March 24, 2026, contained the backdoor, and PyPI quarantined them within roughly an hour. Pin to a version other than those two and verify the resolved version in your lockfile.

How do I know if I was affected by the LiteLLM compromise?

Run pip show litellm to check your version, search your site-packages for litellm_init.pth, and grep your lockfiles for 1.82.7 or 1.82.8. LiteLLM's advisory says to treat any unpinned install or Docker build between 10:39 and 16:00 UTC on March 24 as suspect. If any of those match, rotate the credentials that lived on the host.

What is CVE-2026-33634?

It is the identifier tracking this ecosystem compromise. It was added to CISA's Known Exploited Vulnerabilities catalog on March 26, 2026, and The Hacker News reported on August 12 that the record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 alongside the affected Trivy components.

Why did a compromise of Trivy affect LiteLLM?

LiteLLM's build pipeline ran the Trivy GitHub Action without pinning it to a verified version. When attackers rewrote the action's Git tags to point at a malicious release, that poisoned code executed inside LiteLLM's CI and stole the PyPI publish token from the runner. The attacker then used that token to push the backdoored LiteLLM wheels, so a compromise two tools upstream became a compromise of LiteLLM's releases.