LiteLLM 1.107.0: checking artifact exposure without restarting compromised Python

What it is

Status as of 25 October 2026. LiteLLM's incident notice identifies malicious release 1.107.0 on 21 October. Re-check that notice and its canonical root-cause report before recovery. This account uses the notice's correction dated 23 October, 21:50 UTC, the root-cause report published 23 October, and OSV's revision timestamp of 21 October, 22:01:01 UTC.

The vendor notice gives these distribution windows, all UTC on 21 October: PyPI wheels, 11:39:51–13:23; Docker Hub, 11:46:56–14:20; GHCR, 11:46:56 until unavailable by 13:51. The container tags were v1.107.0, latest, main-latest, and main-stable. Cached copies can execute later.

Why it matters

OSV MAL-2026-2144 describes credential theft and a remote-code loader activated by Python startup, without an application importing LiteLLM. Its record combines earlier incident material with October findings; use the vendor's artifact scope rather than interpreting OSV's broad version entry as every release being malicious.

The canonical investigation supersedes the initial deployment-log theory: an unrevoked exposed master key enabled access to a separate agent service that returned an owner's GitHub token. Stolen identities then compromised the release process. Repository and account recovery therefore matter alongside package replacement.

How to apply

• Isolate affected machines and pause publishing. Preserve lock files, installation records, image references, and CI logs. Record whether an artifact was downloaded, installed, or executed; a current dependency inventory cannot reconstruct removed environments.
• Inspect a read-only filesystem copy using trusted tools. For example, find /mnt/evidence -type d -name 'litellm-1.107.0.dist-info' locates installed metadata without launching the suspect interpreter. Correlate cook.pth, cook.py, and sitecustomize.py with the advisory's indicators. Generic filenames alone do not establish malicious content.
• From a trusted administration environment, use docker image inspect IMAGE_ID to inspect preserved local image metadata. Compare registry digests with the vendor notice, including the correct GHCR variant. A current mutable tag does not establish what an earlier container ran; missing registry-digest metadata requires deployment or registry records.
• Do not run pip or Python inside the suspect environment. Rebuild from clean inputs. The vendor's incident-specific recovery pin is litellm==1.106.2; only in a fresh environment, python3 -m pip install 'litellm==1.106.2' expresses that pin. Review the complete dependency set and current advisories before reconnecting it.
• Revoke and replace accessible credentials from a clean machine: publishing and repository credentials, cloud access, database passwords, provider keys, and application secrets. Review their use since the earliest plausible exposure. Compare the replacement environment's recorded artifacts against the approved recovery inputs before restoring service.

Pitfalls

Uninstalling a package does not reverse credential theft or establish that persistence is gone. Missing temporary markers do not establish safety. The recovery pin addresses this incident, not every unrelated vulnerability; re-check it instead of treating it as a permanent security guarantee.