LiteLLM receives about 23 million weekly downloads — and that reach is exactly why a compromised release can be devastating. Unknown crims inserted a trojanized release (1.107.0) into LiteLLM’s supply chain on Wednesday, distributing malware that steals cloud and AI credentials and runs a remote access trojan (RAT). PyPI quarantined the malicious package within hours, and the Docker image (litellm/litellm:1.107.0) was removed from Docker Hub and GHCR soon after. But anyone who ran the compromised package on any platform should assume their secrets have been stolen.
How the compromise was executed
According to researchers at Google’s Wiz and others, the malicious version was uploaded at 11:39 UTC. The payload traces to malicious commits made on github.com/Berri-AI/litellm — a hyphenated variant of the legitimate BerriAI organization — which attackers used to inject three malicious files into the LiteLLM release pipeline.
The three files are: cook.pth, which causes cook.py to run automatically every time Python is invoked; cook.py, which contains the infostealer; and sitecustomize.py, which serves as the RAT. Python executes both cook.py and sitecustomize.py at interpreter startup. The RAT spawns a background daemon that polls attacker infrastructure every hour for new commands, enabling arbitrary remote code execution on infected hosts.
What the malware collected and how stolen data was exfiltrated
Wiz researchers Benjamin Read and Rami McCarthy say the infostealer harvests data across 16 modules targeting browsers, cloud providers, and AI services. The malware steals browser credentials and cookies from Chrome, Firefox, Edge, and Safari; AWS credentials from ~/.aws/, environment variables, and EC2/ECS instance metadata (IMDS); Google Cloud Platform service account keys and application default credentials; and Microsoft Azure tokens from the CLI cache.
It also harvests API keys for OpenAI, Anthropic, Cohere, and other LLM providers, together with SSH private keys, GPG keys, and shell history files. Collected material is encrypted with AES-256-CBC, the AES key is wrapped with an RSA-4096 public key, and the encrypted payload is sent by HTTP POST to an attacker-controlled endpoint at http://www[.]litellm[.]dev/healthcheck.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleImmediate indicators and containment steps named by researchers
Aikido Security malware hunter Ilyas Makari provided specific indicators: “Check for /tmp/.pc_once_* (the exfil has already fired if this file exists) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if this file exists).” Socket researchers warned: “Teams using 1.107.0 should stop deploying it and investigate environments where Python ran after installation, including proxy containers and CI runners.”
The most recent safe version is v1.106.2. PyPI’s quarantine and the removal of the Docker image do not eliminate risk for systems where the compromised package or image was installed and run; researchers emphasize that operations teams must assume secrets were exposed and hunt for the listed indicators of compromise.
Guidance published by Aikido, Wiz, and Socket
Aikido, Google’s Wiz cloud security business, and supply-chain security provider Socket have each published extensive threat-hunting and mitigation instructions for LiteLLM users and security teams. Their advisories provide technical steps and indicators to search for across developer workstations, CI/CD runners, containers, and deployed systems; the researchers behind those advisories also mapped the malicious files and the infection flow through the release process.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: stop deploying version 1.107.0, inspect any environment where Python ran after installation, and hunt for the /tmp indicators and the background C2 daemon described by Makari. Investigations should include proxy containers and CI runners, per Socket.
- Procurement and IT leaders: treat any systems that consumed the trojanized release as compromised and assume API keys, cloud identities, and database connection strings may have been exposed — the malware targets exactly those artifacts when it runs alongside LLM provider API keys and cloud credentials.
- End users and administrators: if you executed the compromised Docker image (litellm/litellm:1.107.0) or pulled it via latest, main-latest, or main-stable tags, assume secrets are lost and follow the incident response and credential-rotation steps recommended in the published advisories.
This incident echoes an earlier LiteLLM compromise in March that CloudSEK said potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines worldwide — a reminder that supply-chain intrusions can cascade widely when a project is highly downloaded and broadly integrated. BerriAI did not respond to The Register’s inquiries. Researchers and vendors say they will continue to update guidance as further forensic data becomes available.
