LiteLLM Supply Chain Compromise

LiteLLM Supply Chain Compromise:
Overview, Technical Details, and Takeaways

Versions 1.82.7 and 1.82.8 of the Python package distributed via PyPI contained malicious payloads that exfiltrated credentials and sensitive system data to an attacker-controlled server. Its role as a credential proxy is what makes this particular compromise especially severe: LiteLLM, by design, handles API keys and authentication tokens for every provider it brokers access to. A compromise at this layer doesn’t just expose one service; it exposes your entire LLM provider surface area. 

What Do I Need to Know? 

Technical Breakdown: How the Attack Worked 

The attack used two different delivery mechanisms across the affected versions. In v1.82.8, a malicious .pth file (litellm_init.pth, 34,628 bytes) was embedded in the PyPI wheel. Python .pth files placed in  site-packages/  are automatically executed by the Python interpreter on startup or on pip install of the package. No “import litellm” statement is required for the payload to fire. If the affected version was installed on a system, the malicious code executed the moment Python was invoked. In v1.82.7, reports indicate the payload was embedded directly in the proxy server module and executed when requests were proxied through the installation (in the proxy/proxy_server.py file specifically). 

Upon execution, the double base64-encoded payload performed comprehensive host reconnaissance and credential harvesting. More specific details of the exfiltration payload can be found in the GitHub issue on the project here (https://github.com/BerriAI/litellm/issues/24515). The data collection scope was exhaustive:  

• system information (hostname, user, kernel details, network interfaces) 
• a full environment variable dump (capturing all API keys, secrets, and tokens) 
• SSH keys and configuration 
• AWS/GCP/Azure credentials (including EC2 IMDS tokens) 
• Kubernetes secrets and service account tokens 
• CI/CD secrets (Terraform, GitLab CI, Jenkins, Drone) 
• Git credentials 
• database connection strings 
• Docker registry configs 
• SSL/TLS private keys 
• crypto wallet data 
• shell histories 

The collected data was not sent in plaintext. The attacker implemented a proper encryption pipeline: all harvested data was written to a temporary file, encrypted with a random AES-256-CBC session key (generated via openssl rand with PBKDF2 key derivation), and the AES key itself was encrypted with a hardcoded 4096-bit RSA public key using OAEP padding. Both encrypted payloads were packed into an archive and exfiltrated via a silent curl POST to https://models.litellm.cloud/. The use of asymmetric encryption means only the attacker can decrypt the exfiltrated data. 

This attack was designed to be difficult to detect. The .pth execution mechanism bypasses any import-level monitoring. The double base64 encoding evades basic string matching. The exfiltration domain (litellm.cloud) was chosen to closely resemble the legitimate project domain (litellm.ai), reducing the likelihood of detection through casual log review. 

What Do I Need to Do? 

• Determine exposure. 
  • Check whether litellm==1.82.7 or litellm==1.82.8 was installed on any system in your environment.
  • Search for litellm_init.pth in your Python site-packages/ directories.
  • This applies to local development machines, CI/CD runners, Docker containers, and production servers. 
• Assume full compromise on affected systems. 
  • If either version was installed, treat every credential, secret, API key, SSH key, and token that was accessible on that system as exfiltrated.
  • This includes credentials stored in environment variables, config files, cloud provider metadata endpoints, and Kubernetes secrets. 
• Rotate everything. 
  • Rotate all LLM provider API keys, cloud provider credentials (AWS, GCP, Azure), SSH keys, database passwords, CI/CD tokens, Docker registry credentials, and any other secrets that were present on compromised systems. Revoke and reissue Kubernetes service account tokens. 
• Audit access logs. 
  • Review access logs for your LLM providers, cloud accounts, and infrastructure systems for any unauthorized activity originating from the exfiltrated credentials. 
• Pin or migrate. 
  • If continuing to use LiteLLM, pin to a known-good version (version 1.82.6 is being recommended at the time of the writing of this article) and monitor the project’s response closely. Consider whether the official Docker distribution (which was not impacted) is a viable deployment path. Evaluate whether alternative proxy solutions should be assessed as part of your risk posture. 

Bigger Picture and Takeaways 

This incident highlights a growing attack surface in the AI/ML tooling ecosystem. LLM proxy layers occupy a uniquely sensitive position in infrastructure: they are, by definition, credential aggregation points. Every API key for every LLM provider you use flows through them. The same architectural property that makes LLM proxies useful (centralized credential management for multi-provider access) is what makes them devastating when compromised. 

As organizations increasingly adopt AI/ML infrastructure components, these tools become high-value targets precisely because they concentrate authentication material. This is also a reminder that supply chain security in the Python ecosystem remains a persistent challenge. The .pth file execution mechanism is a well-documented feature of Python’s import system, but it continues to be leveraged as an attack vector because it executes code without any explicit import or invocation. 

NetSPI’s AI/ML Penetration Testing services evaluate exactly these kinds of risks across the AI/ML tooling supply chain, including LLM proxy configurations, credential management practices, and CI/CD pipeline security. If your organization is assessing its exposure to this incident or looking to proactively evaluate the security posture of your AI/ML infrastructure, reach out to our team at netspi.com/ai-ml-penetration-testing. 

Additional Resources 

• GitHub Issue #24512: Full Security Disclosure (https://github.com/BerriAI/litellm/issues/24512) 
• Hacker News Discussion Thread (https://news.ycombinator.com/item?id=47502858) 
• Python .pth File Documentation (https://docs.python.org/3/library/site.html)