Forcepoint X-Labs disclosed May 18 a supply-chain attack on LiteLLM, the open-source Python gateway that serves as a unified interface to 100+ LLM providers. Threat group TeamPCP poisoned PyPI releases 1.82.7 and 1.82.8. The attack chain didn't breach LiteLLM's source repository directly — instead, TeamPCP poisoned Trivy (the vulnerability scanner LiteLLM uses in its build pipeline) by impersonating Trivy maintainers and triggering automated release processes to distribute backdoored Trivy binaries. When LiteLLM's CI/CD pulled the compromised Trivy build, the backdoor scraped the runner's memory and exfiltrated a PYPI_PUBLISH token. The attackers then used that token to publish malicious LiteLLM releases directly. Disclosed by Prashant Kumar at Forcepoint X-Labs.
The payload behavior differs across the two versions. Version 1.82.7 used Base64-encoded payloads inside proxy_server.py executing at proxy startup — easier to spot by anyone who diffed the file. Version 1.82.8 was stealthier: it deployed a litelllm_init.pth file in site-packages that activates "at Python interpreter startup on every subsequent process, regardless of whether LiteLLM was ever explicitly imported." That's the key escalation — once installed, the backdoor runs whenever any Python interpreter starts in that environment, not just when LiteLLM is used. The credentials targeted: OpenAI, Anthropic, Microsoft Azure API keys; AWS, Google Cloud, and Azure SDK credentials; kubeconfig and AWS credential files from user home directories. Exfiltration was AES-256-CBC encrypted with a 32-byte session key, sent via curl to models.litellm.cloud. A persistence module called Sysmon.py polled checkmarx.zone every 50 minutes for new instructions.
The architectural lesson is the trust-chain hijack. TeamPCP didn't attack the well-defended LiteLLM repository; they attacked Trivy, which LiteLLM's build process trusted by default. This is the same class of supply-chain attack as xz-utils (the maintainer impersonation that nearly compromised systemd) and the tj-actions npm attack from earlier this year. Any tool in your build process — scanners, formatters, dependency resolvers, linters — is a potential attack surface, even if its actual job is security adjacent. The LiteLLM compromise is especially damaging because LiteLLM's whole value proposition is being the gateway to every major LLM provider. As Prashant Kumar put it: "LiteLLM functions as a unified gateway to major AI providers, meaning a single compromise gave attackers simultaneous access to OpenAI, Anthropic and Azure credentials." If you installed 1.82.7 or 1.82.8, every provider credential the environment touched is potentially in TeamPCP's hands.
Monday: if you have any environment that ran LiteLLM 1.82.7 or 1.82.8, treat every API key the environment had access to as compromised — rotate OpenAI, Anthropic, Azure, AWS, GCP keys immediately, and audit usage logs for unfamiliar requests. Check for the litelllm_init.pth file in your site-packages and the Sysmon.py persistence module. Block egress to models.litellm.cloud and checkmarx.zone at your network layer until you've cleaned the host. For your build pipeline going forward: pin Trivy and every other build-tool dependency to verified hashes (not just versions), require signed releases for security-adjacent tooling, and isolate PyPI publish tokens so they're not accessible to build-time scanners. Forcepoint's writeup didn't disclose the exact timeline, download counts, or BerriAI's response — those gaps make it impossible to estimate exposure precisely. Treat as worst-case until BerriAI publishes a coordinated disclosure.