The LiteLLM PyPI supply chain attack compromised versions 1.82.7 and 1.82.8 with a three-stage credential stealer. Full timeline, technical analysis, and how to protect your AI stack.
On March 24, 2026, someone ran pip install litellm and their machine locked up. CPU pegged. RAM exhausted. Containers killed by OOM errors.
The stack traces pointed back to the LiteLLM package itself. Versions 1.82.7 and 1.82.8 on PyPI had been replaced with backdoored builds containing a credential stealer, a Kubernetes exploitation module, and a persistent backdoor.
LiteLLM is the most widely used open-source AI gateway. It routes requests across LLM providers (OpenAI, Anthropic, Azure, others) through a single interface. At the time of the attack, the package was pulling 95 million monthly downloads from PyPI. That download volume, combined with the fact that AI gateways handle API keys for every model provider and see every prompt in transit, made it a high-value target.
This article breaks down how the attack worked, how it was discovered, and what it means for teams running AI infrastructure.
The LiteLLM compromise did not start with LiteLLM. It started with Trivy, the open-source vulnerability scanner maintained by Aqua Security.
Between March 19 and 23, 2026, the threat group TeamPCP compromised Trivy's CI/CD pipeline. LiteLLM used Trivy as part of its own CI/CD security scanning workflow. When the compromised Trivy action ran inside LiteLLM's pipeline, it exfiltrated the project's PyPI publishing tokens to the attackers.
The key detail: LiteLLM's CI/CD pipeline granted the Trivy scanning step access to the same environment that held publishing credentials. A scanning action does not need write access to PyPI. But the token was available to the compromised process, and TeamPCP extracted it. With valid publishing credentials, the attackers bypassed LiteLLM's official release process and uploaded malicious packages directly to PyPI under the maintainer's account.
TeamPCP compromises the Trivy security scanner. LiteLLM's CI/CD pipeline, which uses Trivy, exfiltrates PyPI publishing tokens to the attackers.
The attackers publish litellm==1.82.7 to PyPI. This version contains malicious code injected into litellm/proxy/proxy_server.py, executed at module import time.
A second malicious version, litellm==1.82.8, is published. This version uses a more aggressive delivery mechanism: a .pth file that executes as soon as the Python interpreter starts, regardless of whether LiteLLM is explicitly imported.
Security researcher Callum McMahon opens GitHub Issue #24512 after his development machine crashes. He had been testing a Cursor MCP plugin that pulled in LiteLLM as a transitive dependency. The crash was caused by a "fork bomb" side effect of the malicious .pth file.
The attacker, still holding maintainer access, attempts to suppress discovery by closing the GitHub issue and flooding the thread with bot-generated comments.
PyPI admins quarantine the entire LiteLLM package, blocking all downloads and removing the malicious versions.
LiteLLM releases v1.83.0 through a rebuilt CI/CD v2 pipeline with isolated environments, stronger security gates, and safer release separation.
The window of exposure was roughly three hours. For a package averaging 3+ million daily downloads, that window was large enough for thousands of installations to pull the compromised versions.
The backdoor was not a simple credential dump. Cycode's analysis revealed a three-stage execution flow designed for maximum reach.
On execution, the malware scanned for over 50 categories of secrets:
.kube/config, .aws/credentials, SSH keys from the home directory.env files, Docker configsHarvested data was encrypted and exfiltrated via HTTPS POST to models.litellm[.]cloud and checkmarx[.]zone, neither of which are affiliated with LiteLLM or Checkmarx.
If the infected library was running inside a Kubernetes cluster, the payload probed the internal Kubernetes API using the local service account token. It enumerated pods, services, and secrets, looking for paths to more privileged nodes or sensitive databases within the cluster.
The malware attempted to install a systemd service called sysmon.service, designed to masquerade as a legitimate system process. Once active, this service began beaconing to a command-and-control server controlled by TeamPCP, polling for additional payloads.
Version 1.82.7 embedded malicious code in proxy_server.py. It ran when the module was imported. Version 1.82.8 escalated the technique.
The attackers placed a file called litellm_init.pth in site-packages/. PTH files are a Python mechanism originally designed for path configuration. Python loads them automatically when the interpreter starts. No import needed. No user action required.
This litellm_init.pth file was 34,628 bytes of double base64-encoded payload. It executed the credential-stealing code as soon as any Python process ran in the affected environment, even if that process had nothing to do with LiteLLM.
That is why McMahon's machine crashed. He installed a Cursor MCP plugin that pulled LiteLLM as a transitive dependency. Python started, loaded the .pth file, and the fork bomb side effect consumed all available RAM.
After McMahon opened the GitHub issue reporting the crash, the attacker used the compromised maintainer credentials to close the issue and flood the thread with bot-generated comments. This was an attempt to bury the disclosure and buy more time before PyPI noticed.
It did not work. The community picked up the signal fast. The original Reddit disclosure on r/Python generated discussion across r/cybersecurity, r/LocalLLaMA, r/programming, and r/webdev, with 280+ combined comments. PyPI quarantined the package within a few hours of the first public report.
LiteLLM's maintainers eventually had to post updates on Hacker News because their GitHub account was also compromised.
This was not a one-off attack. Cycode identified TeamPCP as the threat group behind a multi-ecosystem supply chain campaign that spanned PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX.
The campaign followed a cascading pattern: compromise a widely-used developer tool (Trivy), use that foothold to steal credentials from downstream projects, publish backdoored packages to those projects' registries, then repeat.
LiteLLM is present in roughly 36% of cloud environments, often as a transitive dependency of AI agent frameworks, MCP servers, and LLM orchestration tools. Many teams that were affected did not even know they had LiteLLM in their dependency tree.
pip install litellm between 10:39–16:00 UTC on March 24, 2026pip install litellmghcr.io/berriai/litellm), which pins dependencies| Indicator | What to look for |
|---|---|
| Malicious file | litellm_init.pth in your site-packages/ directory |
| Exfiltration domain | Outbound traffic to models.litellm[.]cloud |
| Exfiltration domain | Outbound traffic to checkmarx[.]zone |
| Installed version | pip show litellm returning 1.82.7 or 1.82.8 |
| Systemd service | sysmon.service installed on Linux hosts |
Treat every credential on the affected system as compromised. API keys, cloud access keys, SSH keys, database passwords, Kubernetes tokens.
Search for litellm_init.pth in site-packages/. Check for the sysmon.service systemd unit. Review /tmp and home directories for unfamiliar files.
Check for outbound connections to models.litellm[.]cloud and checkmarx[.]zone. Look for unusual HTTPS POST traffic from developer machines and CI/CD runners.
Upgrade to litellm>=1.83.0, which was released through a rebuilt CI/CD pipeline with stronger security controls.
Check whether LiteLLM appears anywhere in your dependency tree, even if you do not import it directly. AI agent frameworks and orchestration tools often pull it in.
The LiteLLM incident exposed a specific failure mode: the PyPI publishing token was accessible to a CI/CD scanning step that only needed read access. That one permission gap gave TeamPCP the ability to publish arbitrary code to 95 million monthly downstream installs.
Pin dependencies with hashes. Use pip install --require-hashes or tools like pip-compile to lock packages to specific content hashes, not just version numbers. A compromised version with the same number but different contents would fail the hash check.
Isolate CI/CD credentials. Store PyPI tokens, Docker registry credentials, and cloud keys in isolated secret stores with narrow scope. Separate scanning workflows from release workflows so that a compromised scanner cannot reach publishing tokens.
Monitor for new releases. Tools like Dependabot, Renovate, and Socket track new package versions and flag suspicious changes. A package version appearing outside its normal release cadence should trigger review.
Consider managed alternatives. Self-hosted gateways put dependency management, patching, and release verification on your team. A managed AI gateway handles that as part of the service. SHIM routes LLM traffic through a hosted gateway with built-in PII redaction and security controls, so your team is not running pip install for security-critical infrastructure.
For a full comparison of gateway options after LiteLLM, see our LiteLLM alternatives guide. For the broader picture of LiteLLM's security incidents in 2026, including the June RCE vulnerabilities, see LiteLLM Security: What Went Wrong and What to Do.
LiteLLM's v1.83.0 release on March 30 shipped through a rebuilt CI/CD v2 pipeline. The changes included isolated build environments (scanning and publishing run in separate contexts), additional security gates before package upload, and separation between the release pipeline and dependency-scanning workflows. The project also published SHA-256 checksums for all audited PyPI and Docker releases so downstream users can verify package integrity independently.
36% of cloud environments carry LiteLLM as a transitive dependency. Most of those teams did not choose to install it directly. That is the math that made a three-hour exposure window significant: the blast radius of a compromised AI gateway extends well beyond the teams who knowingly depend on it.
Versions 1.82.7 and 1.82.8, published to PyPI on March 24, 2026. Both contained credential-harvesting malware. Version 1.82.8 was worse: it used a .pth file that executed on any Python interpreter start, not just when LiteLLM was imported. Version 1.83.0 and later were released through a rebuilt, clean pipeline.
By compromising Trivy, an open-source vulnerability scanner that LiteLLM used in its CI/CD pipeline. LiteLLM's pipeline gave the Trivy scanning step access to the same secrets environment that held PyPI publishing tokens. The compromised Trivy action exfiltrated those tokens and TeamPCP used them to publish backdoored packages directly.
No. The official LiteLLM Proxy Docker image (ghcr.io/berriai/litellm) pins dependencies in requirements.txt. Teams running the Docker image were not affected. Teams that built their own Docker images with an unpinned pip install litellm during the exposure window were at risk.
Check for litellm_init.pth in your Python site-packages/ directory. Look for outbound traffic to models.litellm[.]cloud or checkmarx[.]zone in your network logs. Search for sysmon.service in your systemd units. Run pip show litellm to confirm you are not on 1.82.7 or 1.82.8.
Only if your production deployment ran pip install litellm without pinning during the exposure window. Environments using the official Docker image, LiteLLM Cloud, or a pinned version before 1.82.7 were not affected. The GitHub source repository was not compromised — only the PyPI-distributed package.