LiteLLM is the gateway many companies put in front of their models to centralize OpenAI, Anthropic or AWS Bedrock keys. On October 21, someone used its maintainers' own credentials to publish a 1.107.0 with a credential stealer and a backdoor. The instructive part isn't the malware: it's how they got around the release controls.
What Happened, According to LiteLLM's Official Report
LiteLLM published an incident report dated October 21, 2026: the release pipeline was compromised and a malicious litellm==1.107.0 reached PyPI and container registries. The report itself warns that some initial assumptions turned out to be inaccurate or incomplete, so it's best read as an evolving report. Socket, Datadog Security Labs, StepSecurity, OX Security and Mend published analyses of the same incident.
Exposure windows: PyPI, 11:39 to 13:23 UTC; Docker Hub (v1.107.0, latest, main-latest, main-stable), 11:46 to 14:20 UTC. The v1.107.0 code tag in the official repository doesn't contain the malicious files, and according to the report, customers with an enterprise private registry weren't affected.
How the Attack Works: The Pipeline as the Target
The attacker didn't breach PyPI: they used three sets of developers' GitHub CLI OAuth tokens. With one, which had organization-owner permissions, they disabled branch protection and modified the release workflow; with another they met the approval that production required; with the third they erased the trail. Datadog adds that the fork used, Berri-AI/litellm, resembles the legitimate one except for a single hyphen. LiteLLM says release permissions had been temporarily widened that week, which made it easier for two stolen credentials to suffice.
What the Package Did
According to Mend, the seven built wheels came with three extra files. One is a .pth hook that runs every time Python starts, even if you never import LiteLLM; another is a loader that downloads and executes remote code every hour (a RAT-style backdoor, in OX Security's words). The official report names the files cook.pth, cook.py and sitecustomize.py. A Python daemon stays in the background with a lockfile at /tmp/remote_code_loader.lock. Removing just the LiteLLM folder isn't enough: the startup components live outside it.
What to Do If You Installed 1.107.0
- Pin
litellm==1.106.2or another pre-incident version and rebuild images and virtualenvs from scratch. Don't runpip installfirst in the suspect environment: Python re-executes the files at startup. - Delete the files mentioned from every
site-packagesand kill the daemon. - If it ran on a host with internet egress, assume exfiltration: rotate the IAM role, the provider keys stored in the proxy database, master and virtual keys, the
DATABASE_URLpassword and secrets in environment variables. Check CloudTrail forGetCallerIdentitycalls near the install time.