SOFTWARE SUPPLY CHAIN NIGHTMARE: MALICIOUS LITELLM RELEASE EXFILTRATES KEYS, CLOUD CREDS, AND "STEALS MILLIONS IN CRYPTO"
A compromised version of the widely used Python package LiteLLM briefly hit PyPI, and a simple pip install litellm was enough to trigger full credential exfiltration across infected systems.
The malicious releases (v1.82.7 and v1.82.8) weaponized Python’s .pth mechanism, executing code on every interpreter startup, even without importing the package.
Impact was severe:
• SSH keys, cloud creds (AWS, GCP, Azure)
• Kubernetes configs and cluster secrets
• API keys, .env files, CI/CD secrets
• Git credentials, database passwords
• Shell history and crypto wallets
All harvested, encrypted, and exfiltrated to attacker-controlled infrastructure.
LiteLLM sees ~97M monthly downloads, and the real risk came from transitive dependencies. Any project pulling it in, like pip install dspy, was also exposed, massively expanding the blast radius.
The attack was live for under an hour but discovered only due to a bug in the malware itself. A recursive fork bomb crashed a developer’s machine, revealing the compromise. Without that flaw, it may have persisted undetected for days or weeks.
The payload operated in three stages:
Collection: sweeping sensitive files, env vars, and cloud metadata
Exfiltration: AES-256 + RSA encrypted archive sent outbound
Persistence: attempted Kubernetes takeover and system-level backdoors
In K8s environments, it tried to deploy privileged pods across nodes, mount host filesystems, and establish persistent access.
The packages were uploaded directly to PyPI with no matching GitHub release, suggesting a compromised maintainer or API token. Related research ties this to a broader campaign targeting open-source infrastructure.
The GitHub issue was briefly flooded with bot spam and closed, raising further concerns about maintainer compromise during the incident.
The malicious versions have since been removed, but the damage may already be significant.
Early reports suggest real financial losses, including millions in stolen crypto according to Brian Roemmele.

A compromised version of the widely used Python package LiteLLM briefly hit PyPI, and a simple pip install litellm was enough to trigger full credential exfiltration across infected systems.
The malicious releases (v1.82.7 and v1.82.8) weaponized Python’s .pth mechanism, executing code on every interpreter startup, even without importing the package.
Impact was severe:
• SSH keys, cloud creds (AWS, GCP, Azure)
• Kubernetes configs and cluster secrets
• API keys, .env files, CI/CD secrets
• Git credentials, database passwords
• Shell history and crypto wallets
All harvested, encrypted, and exfiltrated to attacker-controlled infrastructure.
LiteLLM sees ~97M monthly downloads, and the real risk came from transitive dependencies. Any project pulling it in, like pip install dspy, was also exposed, massively expanding the blast radius.
The attack was live for under an hour but discovered only due to a bug in the malware itself. A recursive fork bomb crashed a developer’s machine, revealing the compromise. Without that flaw, it may have persisted undetected for days or weeks.
The payload operated in three stages:
Collection: sweeping sensitive files, env vars, and cloud metadata
Exfiltration: AES-256 + RSA encrypted archive sent outbound
Persistence: attempted Kubernetes takeover and system-level backdoors
In K8s environments, it tried to deploy privileged pods across nodes, mount host filesystems, and establish persistent access.
The packages were uploaded directly to PyPI with no matching GitHub release, suggesting a compromised maintainer or API token. Related research ties this to a broader campaign targeting open-source infrastructure.
The GitHub issue was briefly flooded with bot spam and closed, raising further concerns about maintainer compromise during the incident.
The malicious versions have since been removed, but the damage may already be significant.
Early reports suggest real financial losses, including millions in stolen crypto according to Brian Roemmele.

4