LiteLLM 1.107.0 backdoor: how to check exposure and clean up

After reading this, an IT or platform team will be able to work out whether it installed the compromised LiteLLM 1.107.0, remove it, and rotate every credential it may have exposed. Difficulty: moderate.

LiteLLM, an open-source gateway that lets developers call more than 100 large language models through one OpenAI-style interface, had a malicious release quarantined on PyPI on 21 October 2026, and the malicious Docker images removed. According to SafeDep, Socket, StepSecurity and Upwind, version 1.107.0 delivered a credential stealer and a backdoor. LiteLLM's director of security, Oliver Jensen, says the malicious actions ran through three engineers' GitHub accounts, apparently using stolen GitHub CLI OAuth tokens, and that the investigation continues.

The exposure is not niche. LiteLLM sits between applications and model providers, so its hosts tend to hold API keys, cloud tokens and model configuration. That makes this relevant to engineering teams anywhere, and to anyone running AI tooling in CI pipelines or containers.

What you need before starting

• Access to every host, virtual environment, CI runner and container registry that may have pulled LiteLLM. Dependency lockfiles and build logs help.
• Administrative rights to revoke and reissue credentials: cloud IAM, GitHub, SSH keys, AI provider keys and LiteLLM proxy keys.
• A clean machine, separate from anything that ran 1.107.0, from which to do the rotation. The guidance is explicit that credentials should be replaced from a clean environment.
• No cost beyond staff time. Optional: a dependency scanning tool that can block malicious packages at install time.

Step-by-step process

1. Establish whether you pulled the bad version

The affected artefacts are the seven 1.107.0 wheels on PyPI covering Linux, macOS and Windows. PyPI removed the release by 13:23 UTC on 21 October. The Docker images tagged v1.107.0, latest, main-latest and main-stable on Docker Hub and GHCR carried the malicious code between 11:46 and 14:20 UTC. Check build logs, lockfiles and image pull history for those windows. Clean versions are 1.106.2, 1.107.0rc1 and 1.107.0rc2, and the companion packages litellm-proxy-extras 0.4.110 and litellm-enterprise 0.1.78 are also clean.

2. Look for the three injected files

On any suspect host, search site-packages for cook.pth (12 bytes, containing "import cook"), cook.py (22,252 bytes) and sitecustomize.py (25,509 bytes). Their presence confirms the install. The upstream GitHub source does not contain them; the only visible trace in the source distribution is a single extra line, data = "cook", in the maturin build section of pyproject.toml.

3. Isolate and remove

Take affected hosts and containers out of service. Uninstall the package and rebuild from a known-good image rather than cleaning in place. The malware also forks a background daemon that checks a GitHub dead drop every hour and runs whatever Python the attacker serves, so a host may have run attacker-supplied code beyond the stealer.

4. Rotate everything the stealer targets

The first payload is a credential stealer that calls itself privcollect. It gathers cloud tokens, private keys, developer account credentials, AI tooling credential JSON files, Chromium and Firefox browser data, and environment variables. It also tries to extract a LiteLLM proxy's saved credentials and model configuration. The data is packaged into a GZIP-compressed TAR archive and sent to litellm[.]dev/healthcheck by an HTTP POST request. Revoke and reissue cloud keys, private keys, provider API keys, GitHub tokens and proxy secrets, working from a clean machine.

5. Pin the safe release

Pin 1.106.2 by digest.

6. Search for connections to the attacker's infrastructure

Search proxy and DNS logs for connections to litellm[.]dev. The malware also reads a text file (domain.txt) in a GitHub repository, github[.]com/letters9813, and, if it holds a domain, runs the stealer again and fetches and executes the response from that domain's /codepy path. The repository returned a 404 at the time of reporting, but past connections are worth searching for in proxy and DNS logs.

Common mistakes to avoid

• Checking only applications that import litellm. The .pth mechanism runs code at interpreter start, so pip, IDE language servers and CI jobs on the same host were also exposed.
• Rotating from the compromised machine. New secrets created there can be harvested too.
• Trusting the "latest" tag. It was one of the poisoned Docker tags during the window.
• Assuming the incident is closed. Jensen says the mechanism by which the attacker acquired the tokens has not yet been identified, so further access to the GitHub accounts cannot be ruled out.

Tips that make a difference

• Search for the 12-byte cook.pth file across fleets; it is a fast, low-noise indicator.
• Treat this as a recurrence. The same .pth behaviour was observed in the LiteLLM compromise during the TeamPCP supply chain attacks in March, so install-time blocking and delayed adoption of new releases are worth building into pipelines.
• Review AI tooling credential files separately; they are easy to forget in a rotation checklist. The AI agent security checklist is a useful companion.

Key takeaways

• Only 1.107.0 is malicious; pin 1.106.2 by digest.
• Exposure covers the whole host, not just the LiteLLM process.
• Revoke and replace credentials from a clean environment; deleting the package is not enough.

Next steps

Audit who can publish and approve releases in your own pipelines. LiteLLM says the attacker used one engineer's account to trigger the release run and another's to approve it. SafeDep's analysis adds that the attacker used an organisation owner's token to bypass branch protection and point the private release workflow at a lookalike repository, so the official pipeline then built, signed and published the artefacts. LiteLLM has since removed all but one unaffected user from its GitHub organisation, revoked all tokens involved and updated public registries to remove trusted links to its GitHub organisation. Its investigation is ongoing.

Completing the steps above means affected installs are identified, rebuilt and pinned to a clean release, and the credentials the malware targeted have been replaced.