LiteLLM 1.107.0 Compromise: What Happened, Who Is Affected, and How to Clean Up

On October 21, a malicious litellm 1.107.0 reached PyPI and LiteLLM's official Docker images. LiteLLM says its own release pipeline was compromised. The release carried compiled malware that steals credentials and loads remote code.

Here is the detail that should worry every security team. LiteLLM says the official v1.107.0 source tag does not contain the malicious files. Anyone reviewing the code that morning saw a clean project.

The LiteLLM 1.107.0 attack, hour by hour

The attacker used developer credentials that LiteLLM believes were stolen GitHub CLI OAuth tokens. Times are UTC on October 21 and published analyses of the release.

That is about 1 hour 44 minutes on PyPI and 2 hours 34 minutes on Docker. The attacker staged infrastructure a week early and passed the project's own approval gate. Every step went through LiteLLM's real release path.

What the LiteLLM 1.107.0 payload does

The malicious code shipped as compiled files inside all seven wheels. The source distribution carried a tampered pyproject.toml but no payload files.

• Runs at every Python start. Startup hooks named cook.pth and sitecustomize.py launch the payload whenever Python starts. Nothing has to import LiteLLM.
• Takes the keys. It collects LLM provider API keys, cloud credentials, environment variables and the credentials stored in a LiteLLM proxy's own database.
• Sends them out. Stolen data goes to litellm[.]dev, a lookalike domain.
• Leaves a door open. . A background loader checks a GitHub dead drop every hour for remote code to run.

The second time this year

In March, litellm 1.82.7 and 1.82.8 hit PyPI through a stolen publishing token, using a .pth startup hook of the same kind. PyPI measured that window at 2 hours 32 minutes. Researchers say October used different tooling and infrastructure.

The lesson repeats anyway. The code you review and the code you install are two different files, and only the second one runs.

Why reviewing the code missed it

Code review, pull requests and repository scans all read source. The v1.107.0 tag holds no payload, so every source check passed.

Provenance had the same blind spot. This build came out of LiteLLM's own pipeline, approved by a real developer credential. Signed provenance tells you who built a package, and on October 21 the who looked right.

Identity, integrity and intent

Before a package enters a build, three questions decide whether it deserves trust. Each one catches something the other two miss.

Identity: is the publisher who it claims to be?

Identity asks whether today's release matches the history that earned the package its reputation. Signals include account changes, unusual workflows and a release that breaks the usual pattern.

October is the hard case for identity. The release used real credentials and passed a real approval gate, so identity alone could not settle it.

Integrity: does the artifact match its source?

Integrity compares the shipped artifact with the source it claims to come from. It also watches for new files, new dependencies or a jump in size.

October fails this check clearly. The wheels carried startup hooks and compiled files that the v1.107.0 tag does not contain. Integrity needs no understanding of the payload, because it is a comparison. A mismatch is a mismatch.

Intent: does the code do what the package is for?

Intent compares what the code does with what the package says it does. A library that routes LLM requests has no reason to install hooks that run at every Python start, read cloud credentials and call out to an unfamiliar domain.

No single check is enough. In October, identity looked normal because the attacker used real credentials. Integrity and intent both raised a flag, and two independent warnings on the same release are a strong signal.

How CleanStart checks what the registry ships

CleanStart's Tricorder system treats every new version as untrusted until checks on the shipped files pass. It works in four steps:

1. Fetch. A collector watches each registry's feed and downloads the actual package.
2. Read every file that runs. For PyPI that means .py files, setup.py, .pth files, sitecustomize.py and entry points. If the ecosystem's tools will execute a file, Tricorder reads it.
3. Parse for behavior. Each source file becomes a syntax tree in a common form, so one rule covers the same trick in any supported language.
4. Score agreement. Independent checks raise findings, and a correlator scores them higher when they agree on the same release.

Here is what those checks see in 1.107.0.

Identity coming up empty is the reason to ask three questions. Integrity and intent both flag this release, and the correlator scores that agreement above either finding alone. A release scored that way goes to an analyst before it can be promoted into the verified catalog.

Two habits that would have helped

Pin by digest. On October 21, the Docker tags latest, main-latest and main-stable pointed at the malicious image for 2 hours 34 minutes. Anyone who pulled by tag got the bad build. A digest points to one exact image and can't be moved, so builds pinned by digest kept running the version they already had.

Wait until a release is checked. Fast detection only helps if it finishes before you install. PyPI removed 1.107.0 in under two hours, and unpinned pipelines grabbed it in that time. A safer rule is simple: automation installs a new release only after something has inspected it.

A release published minutes ago hasn't been checked by anyone yet, so its safety is unknown, and unknown should mean wait. CleanStart calls this state not yet assessed and holds those versions out of its catalog until the checks finish.

What to do this week

1. Look for 1.107.0. Search images, CI caches and laptops for litellm 1.107.0, cook.pth and unexpected sitecustomize.py files. Check egress logs for litellm[.]dev.
2. Rotate if it ran. LiteLLM advises treating every secret the host could read as stolen, including provider keys stored in the proxy database.
3. Pull by digest. Replace latest and main-stable references with image digests.
4. Add a cooldown. Stop automation from installing releases younger than a few days. In uv, as shown in PyPI's guidance:

1[tool.uv]2exclude-newer = "P3D"  # 3 days as an ISO 8601 duration; needs uv 0.9.17 or later