- Attackers compromised LiteLLM’s PyPI distribution on March 24, 2026, uploading malicious versions (v1.82.7 and v1.82.8) that contained credential-stealing payloads designed to harvest API keys, SSH keys, and cloud provider credentials.
- The compromised packages were live on PyPI for approximately 40 minutes before being quarantined, but the blast radius extended to any system that pulled LiteLLM as a transitive dependency during that window.
- LiteLLM engaged Google Mandiant for forensic analysis and released clean version 1.83.0 on March 30 through a rebuilt CI/CD pipeline.
- Users of the official LiteLLM Docker image and LiteLLM Cloud were not affected because their dependencies were pinned.
What Happened
On March 24, 2026, at 10:39 UTC, attackers uploaded compromised versions of the LiteLLM Python package to PyPI. The malicious releases, versions 1.82.7 and 1.82.8, bypassed the project’s official CI/CD workflows and were published directly to the package registry. PyPI quarantined the packages approximately 40 minutes later, at around 11:19 UTC.
The attack originated from compromised credentials in the Trivy dependency used within LiteLLM’s CI/CD security scanning workflow, according to the security disclosure published by CEO Krrish Dholakia and CTO Ishaan Jaff. The attackers leveraged these credentials to bypass the normal build and release pipeline entirely, publishing directly to PyPI without triggering standard code review or integrity checks.
Why It Matters
LiteLLM is a widely used proxy layer that standardizes API calls across more than 100 large language model providers, including OpenAI, Anthropic, Google, and Azure. It serves as a dependency in numerous AI frameworks, MCP servers, and orchestration tools throughout the AI development ecosystem. A supply chain compromise at this level can cascade into thousands of downstream projects that pull LiteLLM automatically during builds.
The 40-minute exposure window may sound narrow, but automated CI/CD pipelines, Docker builds, and dependency resolution systems can pull and install packages within seconds of publication. Any system that ran pip install litellm without version pinning during that window received the malicious payload. Organizations running frequent automated builds were at highest risk.
The attack also highlights the vulnerability of security tooling itself. The entry point was not a developer’s laptop or a stolen PyPI token but a compromised dependency within the project’s own security scanning infrastructure. Trivy, an open-source vulnerability scanner, became the vector through which attackers gained access to the publishing pipeline.
Technical Details
Version 1.82.7 contained a malicious payload embedded in proxy_server.py, one of the package’s core modules. Version 1.82.8 added a litellm_init.pth file alongside the same payload. The .pth file format is significant because Python automatically executes .pth files at interpreter startup, providing persistence without requiring the compromised module to be explicitly imported by any application code.
The payload functioned as a comprehensive credential stealer. It harvested environment variables, SSH keys, cloud provider credentials for AWS, GCP, and Azure, Kubernetes tokens, and database passwords. The stolen data was encrypted and exfiltrated via POST requests to models.litellm[.]cloud, a domain controlled by the attackers and not associated with LiteLLM’s legitimate infrastructure at berri.ai.
Indicators of compromise include the presence of a litellm_init.pth file in Python site-packages directories and outbound network traffic to models.litellm[.]cloud or checkmarx[.]zone. The LiteLLM team and community contributors published scanning scripts on March 25 to help affected organizations detect these indicators across their environments.
Who’s Affected
Systems that installed LiteLLM via pip without version pinning during the 40-minute window on March 24 are at risk. This includes direct installations, Docker images built with unpinned dependencies during that period, and any project that pulls LiteLLM as a transitive dependency through AI frameworks, agent toolkits, or orchestration platforms.
Users of the official LiteLLM Proxy Docker image from ghcr.io/berriai/litellm were not affected because that image pins its dependencies in requirements.txt. LiteLLM Cloud users were also safe, as were anyone installing from the GitHub source repository, which was not compromised. Systems running version 1.82.6 or earlier that did not upgrade during the incident window are unaffected.
What’s Next
LiteLLM released clean version 1.83.0 on March 30, 2026, through a newly built CI/CD v2 pipeline with isolated build environments and stronger security gates. The team engaged Google Mandiant for forensic analysis, rotated all maintainer credentials, established new authorized maintainers, and published SHA-256 checksums for all verified safe versions from 1.82.0 through 1.82.6.
Affected users should immediately rotate all secrets, including API keys, cloud access keys, database passwords, SSH keys, and Kubernetes tokens. The LiteLLM team recommends searching all filesystems for litellm_init.pth, auditing version histories across local environments, CI/CD pipelines, Docker builds, and deployment logs, and pinning to verified safe versions. A security townhall was held on March 27, and ongoing updates are available through [email protected].
