Key points
- Malicious LiteLLM v1.107.0 was pushed to PyPI and Docker registries on Wednesday, October 21.
- The malware harvested cloud logins, developer secrets, and AI service API keys from installations.
- LiteLLM confirmed the release pipeline was compromised via stolen GitHub CLI OAuth tokens.
The short version
- LiteLLM v1.107.0 contained compiled malware that stole credentials and enabled remote code execution.
- The malicious package remained on PyPI for roughly two hours and on Docker registries for nearly three.
- Users who installed the compromised version are advised to treat their credentials as breached.
The details
LiteLLM stated that its release pipeline was compromised at 4:00 AM PST on October 21, resulting in the push of version 1.107.0 to Docker and PyPI. This specific build included compiled malware designed to steal credentials and load remote-code execution tools. The malicious package stayed on PyPI from 11:39 to 13:23 UTC. Docker images tagged v1.107.0, latest, main-latest and main-stable served the bad build from 11:46 to 14:20 UTC. LiteLLM confirmed that all previous versions are safe and that the impacted releases have been pulled from the registries.
The context
The attacker operated through the GitHub accounts of three LiteLLM engineers, using stolen GitHub CLI OAuth tokens. One account changed the release pipeline, a second approved the release, and a third deleted workflow records. LiteLLM discovered an unexpected user account in its internal deployment, which was exposed to the public internet. The company believes the attacker gained access to this deployment and lifted tokens from its logs. LiteLLM noted that Claude Code can embed GitHub CLI OAuth tokens in response bodies, meaning those tokens may appear in LiteLLM logs if response bodies are logged. The company suspects access occurred through a recently patched vulnerability.
What should you do?
Wiz researchers Benjamin Read and Rami McCarthy identified v1.106.2 as the most recent safe version. Aikido researcher Ilyas Makari advised that anyone who installed version 1.107.0 before it was pulled should treat their credentials as compromised. Users must rotate all affected credentials immediately. Updating alone is not sufficient to mitigate the risk.
For customers and users
Teams should audit their dependency logs to confirm whether any systems pulled version 1.107.0 during the exposure window. If installation occurred, assume all API keys and cloud credentials stored in those environments are compromised. Rotate these secrets immediately. Watch for follow-up phishing attempts that reference this incident to trick users into revealing new credentials. Verify that internal deployments are not exposed to the public internet. Monitor for unusual outbound traffic that could indicate remote code execution tools were loaded.
Background: Malware
No, they are not the same. A virus is a specific subset of malware that attaches to host files and requires execution to spread. Malware is the umbrella term for all malicious software, including worms, trojans, and spyware. Understanding this distinction dictates whether you focus on file integrity or network isolation.
Read the full guide: Is Malware and Virus the Same? A Technical Breakdown
What to do and how to stay safe: LiteLLM
- Check installation logs for LiteLLM version 1.107.0 and revert to v1.106.2 or earlier.
- Rotate all API keys, cloud logins, and developer secrets exposed to the affected environment.
- Monitor cloud accounts for unauthorized access or unusual activity following the exposure.
- Ensure internal LiteLLM deployments are not accessible from the public internet.
General security guidance from the DataSafe Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which LiteLLM version is safe to use?
Wiz researchers state that v1.106.2 is the most recent safe version, and all previous versions are safe.
How long was the malicious version available?
The package was on PyPI from 11:39 to 13:23 UTC and on Docker registries from 11:46 to 14:20 UTC.
Did this incident involve data theft from previous attacks?
This event involved credential harvesting; a separate March attack resulted in a 153GB archive stolen from 2,488 domains.
