LiteLLM 1.107.0 shipped a file called cook.pth. It stole credentials.

LiteLLM, the popular Python library and proxy that puts one interface in front of 100+ model providers, had a bad Wednesday morning. Its 1.107.0 release came with three extra files. One of them was called cook.pth.

What happened. According to LiteLLM's incident post, its release pipeline was compromised early on October 21 and pushed a malicious litellm==1.107.0 to PyPI, Docker Hub and GHCR. All seven PyPI wheels were poisoned and live from 11:39 to 13:23 UTC (about 4:39 to 6:23 a.m. Pacific). The Docker tags v1.107.0, latest, main-latest and main-stable pointed at the bad image from 11:46 UTC until 13:51 UTC on GHCR and 14:20 UTC on Docker Hub. LiteLLM says all earlier versions are safe, the bad artifacts have been pulled, and customers on its private enterprise registry weren't affected.

What the payload does. The analysis in GitHub issue #47826 (credited to the Upwind security research team) and JFrog's write-up agree on the mechanics. pip drops cook.pth, cook.py and sitecustomize.py into the root of site-packages. A .pth file runs on every Python start, so the stealer runs even if your code never imports litellm. The issue lists what it collects: SSH keys, browser passwords and cookies, AWS/Azure/gcloud/kube/docker credentials, .env files, the environment variables of every readable process, AI tool configs, and, if DATABASE_URL is set, the LiteLLM proxy's stored provider keys. Everything is encrypted and POSTed to http://www.litellm.dev/healthcheck, a lookalike domain registered October 13 (the project's real domain is litellm.ai). sitecustomize.py starts a background daemon that checks a GitHub dead-drop every hour for a server to download and run code from; the issue says that stage was dormant at the time of writing.

How it got in, per LiteLLM. After a first compromise in March (JFrog documented backdoored versions 1.82.7 and 1.82.8), LiteLLM says it hardened releases: a private release repo, Trusted Publishing, and publishing only from an account locked to one laptop kept in its office. This time, LiteLLM says, the attacker held GitHub CLI tokens for three developers, including an organization owner, used one to override branch protection, and pointed the release workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm. LiteLLM believes those tokens came from the logs of its own internet-exposed internal LiteLLM deployment, and says it has observed situations where Claude Code embeds a user's GitHub CLI OAuth token in a response body that can end up in logs. LiteLLM says it is still confirming this; we haven't verified it independently.

What to do. Check with pip show litellm and look for litellm-1.107.0.dist-info, cook.pth or a stray sitecustomize.py in site-packages. The advice in the issue and LiteLLM's post starts with a twist: don't start with pip install, because any Python start, including pip, runs the payload again. Delete the three files (and their .pyc copies) from the shell, kill the detached Python daemon holding /tmp/remote_code_loader.lock, then reinstall pinned to litellm==1.106.2, or better, rebuild the venv or image from scratch. If 1.107.0 ever ran on a host with internet access, assume the data left and rotate every credential that host could reach, including every provider key stored in the proxy.

Our take

The joke writes itself: the malware was literally named cook, and it mailed your secrets to /healthcheck. The lesson doesn't. JFrog points out the payload wasn't in the Git tag or the source tarball, only in the built wheels, so reading the source wouldn't have caught it. Pin exact versions (and Docker images by digest), don't let production pull latest, and keep your AI gateway's logs, which can hold other people's tokens, off the public internet.

What we did and didn't do: this story is based on LiteLLM's incident post (as last updated 20:30 UTC), GitHub issue #47826, JFrog's analysis and LiteLLM's X statement, all read October 21, 2026, plus Wiz's post. We didn't download or run the malicious package, inspect the Docker images, or verify LiteLLM's account of the attack chain. We don't know how many installs were affected. Not sponsored; no affiliate links.

MODEL Editors