Loading…
LiteLLM 1.107.0 on PyPI and Docker shipped a credential stealer and backdoor. How to check if you're affected, what to rotate first, and how to clean up.
Claude Mythos 5 opened a malicious GitHub PR during AISI testing and used a fake account to vouch for it. What maintainers and teams running agents should do.
8 min read
One Brotli bug, two names: Node2Shell and HTTP2Shell (CVE-2026-111497). Fixed versions for Node.js, Bun and Python, version checks, patch order and stopgaps.
8 min read
A dense, scannable reference for Model Context Protocol security: threats at a glance, pre-connection checklist, config hardening, detection tools, and a mini IR runbook.
8 min read
Vet a Model Context Protocol server the way this article describes: paste a URL for a live A–F security grade, browse vetted servers in the directory, or read the exact checks behind every grade.
Last updated 22 October 2026, 08:00 IST. LiteLLM's maintainers are still investigating, and I'll update this page if their guidance changes.
If you run LiteLLM anywhere, on a laptop, in a CI job, or as the proxy in front of your agents, set aside an hour this morning. On 21 October a malicious LiteLLM 1.107.0 was published to PyPI and to LiteLLM's Docker tags. It steals credentials and installs a backdoor, and it runs whenever Python starts on the host, even if nothing imports litellm.
This page is the short version for small teams: how to tell if you're affected, what to rotate first, how to clean up, and how to pin so the next bad release doesn't reach production. It's defensive only. There's no malware code here, just indicator names you can search for.
According to SafeDep's analysis, all seven 1.107.0 wheels (Linux, macOS and Windows) install three extra files in site-packages: cook.pth, cook.py and sitecustomize.py. Python processes .pth files and imports sitecustomize at startup, so the payload runs in every Python process on the host, including pip, IDE language servers and CI jobs. The upstream GitHub source doesn't contain these files, and SafeDep says versions 1.106.2, 1.107.0rc1 and 1.107.0rc2 are clean.
LiteLLM's own incident post confirms the affected artifacts and the time windows. Here they are in UTC, with IST alongside:
litellm==1.107.0, live from 11:39 to 13:23 UTC (17:09 to 18:53 IST).v1.107.0, latest, main-latest and main-stable pointed at the compromised image from 11:46 to 14:20 UTC (17:16 to 19:50 IST).litellm, litellm-database and litellm-non_root, from 11:46 UTC until they were made unavailable by 13:51 UTC (19:21 IST).The maintainers say all earlier versions are safe, the bad artifacts have been pulled, and customers on the private enterprise registry weren't affected. Socket, Endor Labs and The Hacker News flagged the PyPI and Docker compromise early, and Socket and Endor Labs put LiteLLM at more than 92 million monthly downloads.
There's no CVE for this. It's tracked as a malicious-package incident, and OSV record MAL-2026-2144 now lists 1.107.0 alongside the versions from LiteLLM's earlier compromise in March.
LiteLLM sits between your apps and agents and every model provider you use, so the host it runs on usually holds a lot of keys at once. SafeDep lists what the stealer goes after: SSH keys, cloud credentials (AWS, Azure, gcloud, kubeconfig, Docker config), CI/CD secrets, AI coding tool tokens and MCP configs, browser-saved passwords, environment variables, cloud instance metadata, and the LLM provider keys stored in a LiteLLM proxy database.
The second file is worse news than the first. SafeDep says sitecustomize.py starts a detached daemon that checks in hourly and downloads and runs whatever code a remote server returns. The GitHub account it read its server address from was deleted about two hours after the release, but hosts that ran the daemon before then could have received second-stage code. On the LiteLLM GitHub issue, a Wiz researcher said Wiz had begun to observe post-exploitation activity. Treat this as a live incident, not a theoretical one.
Check every place LiteLLM could have been installed or pulled on 21 October between about 17:00 and 20:00 IST: developer laptops, CI runners, build servers, containers and the proxy host.
pip show litellm in every virtual environment and image. Anything showing 1.107.0 is affected.litellm pinned to 1.107.0 in requirements*.txt, poetry.lock, uv.lock, Pipfile.lock and pyproject.toml. Also look for unpinned or loose specs (such as a bare litellm or a >= range) in anything that installed during the window.sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e and lists the GHCR digests in its incident post. If you deploy latest, main-latest or main-stable, check what was actually running during the window, not what the tag points to now.litellm-1.107.0.dist-info, cook.pth, cook.py and sitecustomize.py.LiteLLM's guidance is blunt: if Python started with 1.107.0 installed, or a container ran the compromised digest, treat that environment as compromised. Finding the files confirms exposure, but not finding them doesn't prove you're clean, because containers get replaced and temp files get cleaned up.
pip install. Running pip is a Python start, so it runs the payload again. LiteLLM's steps are to delete cook.pth, cook.py, sitecustomize.py and any matching .pyc files in __pycache__ from every affected site-packages using the shell, then kill the detached Python daemon that holds /tmp/remote_code_loader.lock.www.litellm[.]dev, the domain SafeDep says received the stolen data, and alert on any host that tried to reach it.If 1.107.0 ran on a host with internet access, assume the theft worked. LiteLLM says the same. Rotate everything that host could reach, starting with what does the most damage fastest:
GetCallerIdentity calls from the role around install time, then for any use of the role's credentials from outside your infrastructure.DATABASE_URL password. Then check each provider's usage and billing for spend you don't recognise.When you issue the new keys, don't put them back where they were. My AI API key security guide covers scoping, storage and short-lived keys for agents and MCP servers.
The maintainers say to pin to 1.106.2 or another explicit version published before the incident, and LiteLLM releases are paused while they finish the investigation.
pip-compile --generate-hashes does this) and install with pip install --require-hashes -r requirements.txt. Poetry and uv lockfiles record hashes too, so commit them and install from the lockfile in CI.latest and main-stable are exactly how this reached Docker users. Reference images as image@sha256:... and update the digest on purpose.This is LiteLLM's second compromise of 2026, so plan for it to happen again somewhere in your dependency tree.
Rotation fixes the keys that leaked. It doesn't change the fact that an agent holding a key can use it for anything that key allows. A grade finds risk; a gate enforces policy. SentinelAgent Guard puts a runtime policy gate in front of agent tool calls, enforcing 22 controls, so a misused credential or a hijacked agent hits a policy check before it reaches your tools. See Guard pricing.
Was LiteLLM's GitHub source compromised? The official v1.107.0 tag doesn't contain the malicious files, according to both SafeDep and LiteLLM. LiteLLM says the bad artifacts were built from an attacker-controlled lookalike repository: the attacker used stolen developer GitHub CLI credentials to override branch protection and change LiteLLM's private release workflow. LiteLLM is still confirming parts of that chain.
Is 1.106.2 safe? Yes, according to SafeDep and the maintainers, who recommend pinning to it for now.
I never imported litellm. Do I still need to rotate? Yes, if 1.107.0 was installed. The payload runs when any Python process starts on that host, whether or not your code imports litellm.
Is there a CVE? No. It's a malicious-package incident, tracked by OSV as MAL-2026-2144 rather than with a CVE.
Share this article
AWS saw a PHP2Shell attempt on 17 October, four days before PHP's fix. Here's how to check logs, processes and files on PHP-FPM, mod_php and shared hosting.
9 min read
Sign in to leave a comment.