litellm supply-chain exfiltrated API keys

LiteLLM said on March 24, 2026 that two malicious versions of its Python package were published to PyPI after what the company described as a supply-chain compromise tied to a Trivy dependency in its CI/CD workflow. The affected releases were `litellm==1.82.7` and `litellm==1.82.8`, according to LiteLLM and GitHub’s advisory database. GitHub reviewed the incident as a critical security issue and said the malware harvested sensitive files and credentials before exfiltrating them to a remote API. PyPI said the compromised LiteLLM versions were downloaded more than 119,000 times during the exposure window. LiteLLM said the packages were live from 10:39 UTC on March 24 for about 40 minutes before PyPI quarantined them, while PyPI’s incident report measured total exposure time at 2 hours and 32 minutes from upload to quarantine. PyPI said LiteLLM is typically installed 15 million to 20 million times a week. (docs.litellm.ai) ### Which LiteLLM versions were compromised, and how did they run? GitHub issue reports from the LiteLLM repository said version 1.82.7 carried a payload embedded in `litellm/proxy/proxy_server.py`, triggered when `litellm.proxy` was imported. The same reports said version 1.82.8 added a `litellm_init.pth` file that executed on Python startup, meaning the malicious code could run without importing LiteLLM at all. (docs.litellm.ai) GitHub’s advisory database said affected versions were `>= 1.82.7` and `<= 1.82.8`, with no patched version listed in that advisory entry at publication time. LiteLLM later said it released a new clean version, `v1.83.0`, on March 30 through what it called a new CI/CD v2 pipeline. ### What kinds of credentials were exposed? LiteLLM’s incident timeline said the malicious code collected SSH keys, environment variables, cloud credentials and API keys, including credentials for AWS, Google Cloud, Azure and Kubernetes environments. (github.com) The same company update said official LiteLLM Proxy Docker image users were not affected because that deployment path pinned dependencies in `requirements.txt` and did not rely on the compromised PyPI packages. (github.com) GitHub’s advisory said anyone who installed and ran the project should assume credentials available to the LiteLLM environment may have been exposed and should revoke or rotate them. That warning covered API tokens and other secrets reachable from the infected runtime, not only LiteLLM-specific credentials. ### Did the malware use DNS tunneling? Public vendor and platform disclosures reviewed here describe exfiltration to remote infrastructure, but they do not confirm DNS tunneling. (github.com) LiteLLM’s GitHub issue said the malware exfiltrated data with a `curl POST` request to `models.litellm.cloud`, and GitHub’s advisory described exfiltration to a remote API. PyPI’s incident report likewise said the malware harvested credentials and files and exfiltrated them to a remote API. (github.com) Trend Micro’s March 26 analysis said the payload encrypted sensitive data before exfiltration and linked the incident to a broader campaign it attributed to TeamPCP. That report described credential harvesting, Kubernetes lateral movement and persistence, but the materials reviewed did not independently verify DNS tunneling as the exfiltration method. (github.com) ### How did LiteLLM say the compromise started? LiteLLM said it believed the compromise originated from the Trivy dependency used in its CI/CD security scanning workflow. PyPI’s incident report used similar language, saying the malicious LiteLLM releases were published after an API token exposure from an exploited Trivy dependency. Trend Micro said the LiteLLM incident was part of a wider supply-chain campaign spanning multiple ecosystems and attributed the operation to a threat actor it tracks as TeamPCP. (trendmicro.com) LiteLLM’s GitHub issue also said the maintainer’s PyPI account appeared to have been hijacked and that the malicious versions were uploaded directly to PyPI rather than through the project’s official GitHub release process. (docs.litellm.ai) ### What should affected users do now? LiteLLM said all maintainer accounts had been rotated, the compromised packages had been deleted, and no new releases would be issued until the release chain had been reviewed. The company said users should check whether versions 1.82.7 or 1.82.8 were installed, treat exposed credentials as compromised, and update to a verified safe release. (trendmicro.com) On March 30, LiteLLM said `v1.83.0` was available as a clean release and published verified safe versions with SHA-256 checksums. GitHub’s advisory for the affected versions remained available as of its March 26 update, and PyPI said both LiteLLM and Telnyx had since adopted Trusted Publishers after the incident. (docs.litellm.ai) (github.com)