Trojanized LiteLLM, a popular gateway to AI models, stole cloud credentials

It took just seven minutes. On October 21 at 11:39 UTC (1:39 p.m. in Paris), seven LiteLLM 1.107.0 packages appeared on PyPI, the public repository for Python libraries. At 11:46, the automated scanner from the company Socket raised the alarm. But the tainted version was already available for download by any deployment pipeline.

LiteLLM is an open source library and gateway: it lets developers query dozens of AI models (OpenAI, Anthropic, Google…) through a single interface. According to Socket, it is downloaded about 23 million times a week. In its incident report, the project confirms that its publishing process was compromised and that this version "contained compiled malware that steals credentials and loads remote code execution tools." The enterprise version, distributed through a private registry, is not affected.

What the tainted version went after

The attackers did not modify LiteLLM's code. They added three files to the installation package: cook.pth, cook.py and sitecustomize.py. These files run every time Python starts in the affected environment, even if LiteLLM is never called.

Socket and Endor Labs analyzed the program. Among other things, it harvests:

• AWS, Azure, Google Cloud and Kubernetes credentials;
• SSH keys and .env files;
• GitHub, npm and PyPI tokens;
• login files for AI tools such as Codex, Claude, Gemini or Cursor;
• browser data;
• AI provider keys stored in LiteLLM's database.

The loot is encrypted and sent to a domain that imitates the project's. A downloader then stays active to fetch and run remote Python code.

The packages were removed from PyPI at 1:23 p.m. UTC. On Docker Hub, the images tagged v1.107.0, latest, main-latest and main-stable remained tainted until 2:20 p.m. UTC. One important point: an installation set to "latest", which always pulls the newest version, may have fetched the tainted image without ever requesting 1.107.0.

How did the attackers get in?

The incident report retraces the morning. At 10:08 UTC, a GitHub protection rejected a change to the publishing process. Five seconds later, the credentials of a developer with elevated rights were used to override it. The attackers then pointed the publishing pipeline at a lookalike repository, "Berri-AI/litellm," which differs from the real one only by a hyphen. A second credential approved the release to production. A third erased the traces of the runs. On Monday, October 19, publishing rights had been widened so that two engineers could publish fixes.

Where did these credentials come from? LiteLLM puts forward a hypothesis that it does not present as confirmed. An unknown account was discovered on an internal LiteLLM server exposed to the internet, whose logs could record the content of responses. According to the project, Anthropic's coding agent Claude Code can include the user's GitHub token in its responses. How the attacker got into that server is still unknown: the team suspects a recently patched vulnerability. We found no public reaction from Anthropic. According to BleepingComputer, LiteLLM had already been compromised in March 2026 by the TeamPCP group, through the Trivy tool used in its publishing pipeline.

What to do if you use LiteLLM

The usual reflex, uninstalling and then reinstalling with pip, is the wrong one here: every Python launch, pip included, reruns the malicious code. Here is what LiteLLM and Socket recommend:

• check your dependency files, caches, build logs and running containers: any trace of 1.107.0 or of an image pulled on October 21 between 11:46 a.m. and 2:20 p.m. UTC indicates a compromise;
• without launching Python, delete cook.pth, cook.py, sitecustomize.py and the corresponding .pyc files from the terminal;
• stop the process holding the file /tmp/remote_code_loader.lock;
• rebuild environments and images from scratch, pinning version 1.106.2;
• if the machine had internet access, assume the secrets were stolen: rotate the AI provider keys stored in LiteLLM, the master key and virtual keys, the database password, cloud roles and any secret present in the environment;
• on AWS, look in the CloudTrail log for GetCallerIdentity calls at the time of installation, and for any use of these credentials from outside.

The case recalls the OVHcloud command-line tool trojanized on GitHub and the AI keys exposed at OpenCode. LiteLLM promises further updates to its investigation. It also announces the disclosure, on October 27, of another vulnerability still under embargo.