# The poisoned LiteLLM 1.107.0 problem, and the 30-second check I now run on every repo

> Source: <https://dev.to/xm-yang/the-poisoned-litellm-11070-problem-and-the-30-second-check-i-now-run-on-every-repo-570c>
> Published: 2026-10-23 00:05:54+00:00

On Oct 21, LiteLLM disclosed that v1.107.0 shipped compromised — malicious wheels on PyPI (live 11:39–13:23 UTC), poisoned Docker tags (`v1.107.0`, `latest`, `main-latest`, `main-stable`, 11:46–14:20 UTC), and GHCR images (until 13:51 UTC). The official announcement: [https://docs.litellm.ai/blog/security-incident-oct-21-2026](https://docs.litellm.ai/blog/security-incident-oct-21-2026)

The part that caught people off guard: in an affected environment, *any* Python start re-runs the implant. So the vendor's own response steps warn you **not** to start with `pip install` or `pip show` on a suspect box — you check files and metadata first, from the shell.

I turned the announcement's manual steps into a small checklist I now run on every repo and venv folder. Here's the method, then the tool that automates it.

`litellm==1.107.0` pinned = exposed. But `litellm>=1.0`, `~=1.107`, `^1.107.0`, or unpinned `litellm` in requirements/pyproject/Poetry files = `poetry.lock`, `uv.lock`, `Pipfile.lock` for a resolved `v1.107.0` = exposed; `latest` / `main-latest` / untagged images pulled during Oct 21 11:46–14:20 UTC = suspect. Also compare against the compromised image digest published in the announcement.`litellm-*.dist-info/METADATA` directly in site-packages. If it says 1.107.0, treat the environment as compromised: rebuild from `litellm==1.106.2`, rotate every secret that box could reach, check CloudTrail.`cook.pth`, `cook.py`, a planted `sitecustomize.py`, and `/tmp/remote_code_loader.lock` (the C2 daemon ran or is still running if that lockfile exists).
I packaged the above as `litellm-check` (13 rules, each mapped to a step in the official announcement), because I kept seeing "how do I know if I was exposed?" in issue threads:

```
pip install litellm-check
litellm-check scan ./your-project        # code side
litellm-check scan ~/.virtualenvs        # installed-env side
```

Output is a Markdown or JSON evidence report — file:line, the matched spec/tag, and the announcement basis for each finding. `--fail-on critical` works as a CI gate. Zero third-party dependencies, Python 3.11+, Apache-2.0.

**The honest limit, printed on every report:** a clean scan means "none of the known indicators were found" — nothing more. Environments rebuilt after exposure, images pulled without a definition file in the tree, or CI-only installs leave nothing on disk to find. This is evidence collection, not a safety certification.

If your stack exposes LiteLLM somewhere these 13 rules miss, rule PRs with fixtures are the most useful contribution.