LiteLLM 1.107.0 supply chain compromise: what to check, what to rotate and the 2026 CVEs

What happened to LiteLLM 1.107.0

LiteLLM is a widely used open-source gateway that puts one OpenAI-style API in front of many model providers. It usually holds every provider key an organisation owns. That makes a backdoored release very valuable to an attacker.

The malicious release was not built from LiteLLM’s source. According to LiteLLM’s root-cause analysis, the attacker used stolen maintainer tokens to point the legitimate release pipeline at a lookalike fork. The official v1.107.0 tag on GitHub is clean, and the payload only exists in the built wheels and images. All times below are UTC on 21 October 2026.

LiteLLM says customers on its private enterprise registry were not affected. No source we read gives a download count for 1.107.0. The 92 million monthly downloads quoted in the press are for the project as a whole.

How the attacker got in

The root cause goes back months. On 27 May 2026 a configuration file committed to a public LiteLLM repository leaked the master key of an internal agent platform, and that key was never revoked. On 10 October the attacker used it to obtain a GitHub organisation owner’s CLI token. Throwaway CI workflows then sent two more maintainers’ tokens to an external webhook. LiteLLM had also recently relaxed release approval to allow any two engineers. With the three stolen tokens, the attacker overrode branch protection, approved the release and erased the traces. LiteLLM’s first post blamed a different path, and its later analysis corrected that, so rely on the attack-chain post.

What the malware does

JFrog and Microsoft analysed the payload:

• It runs without being imported. The wheel drops cook.pth, which Python executes at every start, including pip itself. That file loads cook.py, a stealer the authors call “privcollect”.
• It steals almost everything it can read:
  • environment variables of the current process and of every readable /proc/*/environ;
  • cloud credentials and instance metadata (AWS, Azure, GCP), Kubernetes and Docker configuration;
  • SSH, GPG and TLS keys, browser data, Git, package registry and AI tool tokens;
  • the provider credentials in LiteLLM’s own database (LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable), reached through DATABASE_URL.
• It sends the data out encrypted (AES-256 plus RSA-4096) over plain HTTP to a lookalike domain.
• It installs a loader. sitecustomize.py starts an hourly loader on Linux and macOS that fetches code from an address published in a GitHub file. That file was empty when the researchers checked, and no second stage has been confirmed.

Am I affected?

You are at risk if any of these is true:

• you installed litellm==1.107.0 from PyPI between 11:39 and 13:23 UTC on 21 October, by hand, in CI, or through a dependency range that allowed it;
• you pulled or started a LiteLLM image from Docker Hub or GHCR between 11:46 and 14:20 UTC under v1.107.0, latest, main-latest or main-stable, including automatic pulls by a scheduler, autoscaler or deployment.

Check without starting Python in the suspect environment:

# files the wheel left in site-packages (no output is not proof of a clean host)
find / -path '*site-packages*' \( -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \
  -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null
ls -la /tmp/remote_code_loader.lock /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null

# the image digest you are running
docker images --digests | grep -i litellm

The marker files only prove infection when present. Containers and /tmp cleanup remove them.

What to do now

1. Don’t run pip or python in the affected environment first. Both start the stealer again.
2. Delete cook.pth, cook.py, sitecustomize.py, __pycache__/cook*.pyc and sitecustomize*.pyc from every site-packages directory. Then kill the detached Python process that holds /tmp/remote_code_loader.lock.
3. Rebuild virtual environments and images from scratch rather than cleaning them in place. Pin an exact version (LiteLLM’s advice was 1.106.2; 1.106.3 and 1.106.4 have since been published).
4. If the host had outbound internet access, assume the data was sent. Rotate:
   • every provider key stored in the LiteLLM proxy database;
   • the LiteLLM master key and all virtual keys;
   • the DATABASE_URL password;
   • the instance or task IAM role and any cloud keys;
   • every secret in the environment of any process on that host;
   • SSH, GPG, Git and package registry tokens.
5. In AWS, look in CloudTrail for GetCallerIdentity calls from the instance role around the install time, then for use of that role from outside your network. Do the same in your providers’ usage dashboards.
6. Block the indicators below at your egress proxy or DNS resolver, and search past logs for them.

Indicators of compromise

These come from LiteLLM, JFrog and Microsoft. Domains are defanged.

Microsoft also publishes SHA-256 hashes of the startup files and Defender detection names (Trojan:PyPI/LiteLlmSupplyChain) in its write-up.

Harden the next upgrade

• Install Python dependencies from a lock file with hashes (pip install --require-hashes -r requirements.txt, or uv or Poetry lock files). A new upload under an old version then fails instead of installing.
• Deploy images by digest (berriai/litellm@sha256:…), never by latest or main-*. Let a person or a bot open the upgrade, and wait a day before taking new releases of critical components.
• Give the gateway’s host as little as possible: no broad cloud role, no SSH keys, no unrelated secrets in its environment, and outbound traffic limited to the model providers it needs.

LiteLLM CVEs of 2026

The supply chain attack came after a year of serious bugs in the LiteLLM proxy itself. This table collects them from the GitHub advisories and CVE records. CVSS is the highest score given in the record. Every 1.106.x release is newer than all the affected versions listed.

Two caveats from the sources. CVE-2026-93355 has no LiteLLM advisory and no fixed version in any record, and the CVSS scores differ between OX Security and the CVE record. The GitHub data for GHSA-3cv6-jpf6-8222 also gives inconsistent ranges, so rely on the fixed-version list. None of the sources we read report in-the-wild exploitation of these CVEs.

How a WAF helps, and where it doesn’t

To be clear first: a WAF can’t stop the 1.107.0 malware. It ran inside your own host at Python start-up and sent data out. A reverse proxy in front of your incoming traffic never sees that. Pinning, hashes and rotation are the defence.

What OpenWAF does for a LiteLLM gateway (or any AI API) that is reachable from the internet:

• Host header validation. The OpenWAF edge routes by Host and answers 421 Misdirected Request to any host that isn’t a configured name, before any filtering or contact with the origin. A crafted Host never reaches LiteLLM through OpenWAF, which is exactly the upstream control LiteLLM’s advisory for CVE-2026-49468 recommends.
• Protection for AI endpoints (Bots and AI agents). For paths such as /v1/chat/completions you can set:
  • request-rate limits per IP or per session;
  • a body size cap;
  • fixed checks that reject runaway requests, such as very large max_tokens, many parallel completions or thousands of messages;
  • prompt-injection detection.
  It starts in log mode. These are request limits, not token accounting.
• Rate rules and an access gate for the admin side. Put tighter rate limits on key and user management routes, restrict them by IP or country, or put the admin UI behind the access gate with one-time e-mail codes.
• An origin that only answers OpenWAF. With authenticated origin pulls (mTLS), the edge presents a client certificate and your server can refuse every connection that doesn’t come through OpenWAF, so these controls can’t be bypassed by hitting the origin directly. The client CA is shared across the platform: it proves the connection comes from the OpenWAF edge, not that it is for your zone, so keep checking Host as well.

Limits: the authenticated CVEs (42271, 47101, 47102, 84377, 114612) and the JWT takeover (93355) use valid credentials and normal-looking API calls, which no WAF can tell apart from real use. The SQL injection in CVE-2026-42208 sat in API key verification, where generic WAF rules may not look. Updating LiteLLM is the fix.

Checklist

1. Find every LiteLLM install: servers, containers, CI images, notebooks and developer laptops.
2. Check whether 1.107.0 or the affected image tags ran between 11:39 and 14:20 UTC on 21 October, using the commands above and your deploy and pull logs.
3. On affected hosts, remove the startup files without running Python, then rebuild from a pinned, hash-checked version.
4. Rotate the provider keys in the LiteLLM database, the master and virtual keys, DATABASE_URL, cloud roles and every secret those hosts could read.
5. Review provider usage, CloudTrail and Git audit logs for activity after 21 October.
6. Block and search for the IOCs at your egress proxy and DNS resolver.
7. Make sure no LiteLLM older than 1.106.x is exposed anywhere. The 2026 CVEs make old versions dangerous even without the supply chain attack.
8. Put the gateway behind a WAF that validates Host, rate-limits the AI endpoints and gates the admin UI, and lock the origin to it.

Frequently asked questions

Sources

• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised LiteLLM, Oct 21, 2026
• The attack chain behind the v1.107.0 LiteLLM release LiteLLM, Oct 23, 2026
• LiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code JFrog Security Research, Oct 21, 2026
• Inside the LiteLLM 1.107.0 supply chain compromise: credential theft through Python startup hooks Microsoft Security, Oct 23, 2026
• LiteLLM release pipeline hacked to distribute info-stealer malware BleepingComputer, Oct 22, 2026
• GHSA-4xpc-pv4p-pm3w: Authentication Bypass via Host Header Injection (CVE-2026-49468) LiteLLM, May 28, 2026
• GHSA-7488-6r32-c95q: MCP OAuth2 passthrough authentication bypass (CVE-2026-59822) LiteLLM, Jun 30, 2026
• GHSA-v4p8-mg3p-g94g: command execution via MCP stdio test endpoints (CVE-2026-42271) LiteLLM, Apr 21, 2026
• GHSA-r75f-5x8p-qvmc: SQL injection in proxy API key verification (CVE-2026-42208) LiteLLM, Apr 20, 2026
• GHSA-qrc4-49gv-mv9m: privilege escalation via allowed_routes (CVE-2026-47101) GitHub Advisory Database
• GHSA-wpfp-gwwc-vwq6: self role change via /user/update (CVE-2026-47102) GitHub Advisory Database
• GHSA-3cv6-jpf6-8222: SSRF and provider credential exfiltration (CVE-2026-84377) LiteLLM, Aug 26, 2026
• GHSA-7hp6-4w63-5g45: internal_user to proxy_admin and RCE (CVE-2026-114612) LiteLLM, Sep 30, 2026
• LiteLLM: an ordinary login token can become someone else’s admin account (CVE-2026-93355) OX Security, Sep 29, 2026