LiteLLM PyPI breach exposed AI credentials after attackers pushed malicious versions 1.82.7 and 1.82.8

LiteLLM, a widely used Python library for routing requests across multiple LLM providers, was compromised on PyPI after attackers published two malicious releases, versions 1.82.7 and 1.82.8. LiteLLM’s own incident update says the packages were unauthorized, were later removed from PyPI, and may have exposed credentials on any system that installed or ran them during the affected window on March 24, 2026.

Security researchers at Endor Labs and JFrog say the malicious code did not come from the upstream GitHub repository. Instead, it was injected into the PyPI distributions after an attacker gained access to the publishing path, which makes this a supply chain compromise rather than a source-code backdoor in the public repo. LiteLLM’s GitHub and incident pages say the maintainer’s PyPI account or publishing chain was likely compromised, and the team believes the breach may link back to the wider Trivy compromise.

The affected versions were short-lived, but the risk was still severe. LiteLLM says users may have been exposed if they installed or upgraded the package between 10:39 UTC and 16:00 UTC on March 24, 2026, or if an unpinned dependency pulled in one of the bad releases during that window.

Endor Labs describes LiteLLM as a package with more than 95 million monthly downloads, which explains why this compromise drew immediate attention across the AI and developer tooling ecosystem. I could verify that number through Endor Labs’ write-up, but I did not find a separate primary PyPI statistics page in the sources I reviewed, so I would treat the “95 million” figure as vendor-reported unless you want me to dig deeper into download telemetry sources.

What attackers put into the package

Version 1.82.7 contained a malicious payload inside litellm/proxy/proxy_server.py, according to LiteLLM, Endor Labs, and JFrog. Version 1.82.8 went further by also including a litellm_init.pth file, which Python can execute automatically at interpreter startup when placed in site-packages. That meant 1.82.8 could trigger even if the victim never directly imported LiteLLM in code.

Researchers say the malware acted as a credential stealer. LiteLLM’s own incident note says the payload scanned for environment variables, SSH keys, cloud provider credentials for AWS, GCP, and Azure, Kubernetes tokens, and database passwords, then exfiltrated the data to models.litellm.cloud, which the company says is not an official LiteLLM domain. JFrog and other researchers also linked the malicious payload to TeamPCP, a threat actor tied to recent supply chain attacks across developer infrastructure.

Multiple research teams say the malware also attempted persistence and broader compromise. JFrog, Datadog, Sonatype, and others describe a three-stage flow that included credential harvesting, Kubernetes-focused lateral movement, and a persistent backdoor component. Those details appear consistently across several security write-ups, but LiteLLM’s own official incident page stays more conservative and focuses mainly on the credential theft and exfiltration risk.

Affected versions and status

This table reflects LiteLLM’s official incident update and GitHub security issue.

Who was affected and who was not

LiteLLM says you may have been affected if you installed or upgraded LiteLLM through pip during the March 24 window, built a Docker image that installed an unpinned LiteLLM dependency, or pulled it transitively through another AI framework or orchestration tool.

The company also says several groups were not affected. That includes LiteLLM Cloud users, users of the official LiteLLM Proxy Docker image, users who stayed on version 1.82.6 or earlier, and users who installed LiteLLM from source via the GitHub repository instead of PyPI.

That distinction matters because some headlines made the breach sound universal. It was not. The exposure centered on the compromised PyPI packages and the specific install window, not every LiteLLM deployment path.

Why this breach matters

LiteLLM often sits in high-trust environments because it connects multiple model providers, API keys, cloud services, and internal tooling. A compromise in that position can give attackers access to more than one secret store at once. That is why researchers described the incident as especially dangerous for AI pipelines, developer workstations, CI systems, and Kubernetes-backed applications.

The incident also fits a larger pattern. Datadog, Endor Labs, Snyk, Arctic Wolf, and others say the LiteLLM breach appears linked to a broader TeamPCP campaign that also hit Trivy, Checkmarx KICS, and other parts of the software supply chain over the same period.

What users should do right now

• Check whether litellm==1.82.7 or litellm==1.82.8 was installed anywhere in local environments, CI jobs, container builds, or production systems.
• Inspect site-packages for litellm_init.pth, especially on systems that may have pulled 1.82.8.
• Treat any affected system as potentially compromised and rotate credentials, including SSH keys, cloud secrets, API keys, Kubernetes tokens, and database passwords.
• Investigate outbound traffic to models.litellm.cloud and checkmarx.zone, both listed by LiteLLM as indicators of compromise or suspicious domains tied to the incident.
• Pin LiteLLM to 1.82.6 or another later verified safe release once the project resumes trusted publishing.

FAQ