LiteLLM CVE-2026-42271 and the 1.107.0 Backdoor: What Operators Should Do

If you run LiteLLM as the gateway between your apps and AI providers, October 21 delivered two problems at once. A release that should never have existed, LiteLLM 1.107.0, went up on PyPI that day carrying what SafeDep describes as “a credential stealer and a remote code execution backdoor.” At the same time, three older LiteLLM bugs, led by LiteLLM CVE-2026-42271, sit in CISA’s Known Exploited Vulnerabilities (KEV) catalog, the agency’s list of flaws with evidence of exploitation in the wild.

Where it stands: PyPI pulled 1.107.0, and BerriAI, the company behind LiteLLM, wrote on its GitHub incident thread that “The malicious docker images have been removed.” Its instruction to open-source users: “please pin your version to 1.106.2 or any explicit version published prior to now.” BerriAI says it has not finished confirming how the attacker got in. A separate, embargoed LiteLLM fix is due for disclosure on October 27; nothing about it is public yet.

Two different problems on the same gateway

It helps to keep these apart, because the fixes differ.

• The 1.107.0 package compromise is a supply-chain attack. The code you installed was tampered with before it reached you. It has no CVE number. Upgrading past it does not undo what it already took.
• The three KEV-listed CVEs are bugs in genuine LiteLLM code. Patched versions exist, and CISA’s catalog says attackers have exploited them.

Both matter for the same reason. A LiteLLM proxy usually holds the real API keys for every model provider a team uses, and JFrog’s researchers put it plainly: “A compromised proxy host can therefore expose credentials for many upstream AI providers at once.” JFrog also calls this “the second documented hijacking of LiteLLM in 2026,” but adds that “No evidence currently links it to TeamPCP or the earlier access path, so the incidents should be treated as separate campaigns.”

What the 1.107.0 release did

According to SafeDep’s timeline, all eight 1.107.0 files were uploaded to PyPI between 11:39 and 11:40 UTC (7:39 to 7:40 a.m. ET) on October 21. They added three files the real source code does not contain: cook.pth, cook.py and sitecustomize.py.

Python runs both kinds of file automatically at startup. SafeDep explains that “the stealer runs in every Python process on the host: the application, pip, IDE language servers, and CI jobs.” The stealer’s job list includes reading DATABASE_URL and dumping two LiteLLM tables, the ones that, in SafeDep’s words, “hold the LLM provider API keys of a LiteLLM proxy.” It also sweeps SSH keys, cloud credentials, browser passwords and CI secrets from the machine.

sitecustomize.py is a persistent loader. SafeDep found that “Every hour, the daemon reads a server address from a GitHub file, runs the stealer again, and downloads and runs code from that server.” Docker users were exposed too. JFrog warns that systems that pulled the latest, main-latest or main-stable tags while they pointed at 1.107.0 “should be treated as exposed as well.”

How the attacker published it is still under investigation. In its preliminary account, BerriAI says it believes the attacker took developers’ GitHub CLI tokens from the logs of an internet-exposed internal LiteLLM deployment. It adds: “We have not yet confirmed how the attacker gained access to our internal deployment, but currently suspect it was through a recently patched vulnerability.”

Signs a host ran the backdoor

These indicators come from SafeDep’s and JFrog’s write-ups. Check every virtual environment, container image and CI runner that installs LiteLLM.

A clean result on the marker files is weak evidence. The researcher who opened the GitHub issue wrote: “If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded. If the marker file exists, the exfil is confirmed. If it doesn’t, that proves nothing: containers and tmp cleanup remove it.”

LiteLLM CVE-2026-42271 and the other KEV-listed flaws

Separately from the package attack, CISA’s KEV feed (catalog version 2026.10.21) lists three LiteLLM vulnerabilities. Version ranges and fixes come from each NVD record.

CVE-2026-42271 (NVD CVSS 3.1 score 8.8, High) sits in two endpoints used to preview an MCP server. NVD says “Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host.” For teams that cannot upgrade at once, the LiteLLM advisory gives a workaround: “block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at your reverse proxy or API gateway.” The fix makes both endpoints require the PROXY_ADMIN role.

CVE-2026-42208 needs no login at all. A crafted Authorization header sent to any model route reaches a database query, and NVD says the result can be “unauthorised access to the proxy and the credentials it manages.” Its CVSS 4.0 score from GitHub is 9.3 and NVD’s own CVSS 3.1 score is 9.8, both Critical.

CVE-2026-59822 (NVD CVSS 3.1 score 8.2, High) let an unauthenticated attacker with a fabricated Authorization header reach MCP tooling “without a valid LiteLLM key,” per NVD.

One catch: BerriAI’s pin advice allows any explicit version published before the bad release. 1.106.2 is a later release than 1.84.0, but teams that pinned something older to escape 1.107.0 should check it against this table, or they may have traded one known-exploited problem for another.

The October 27 fix nobody outside can see yet

In the same GitHub thread, BerriAI said: “There currently exists a private LiteLLM registry for enterprise customers, in which we are distributing an embargoed release that remediates a vulnerability whose disclosure date is scheduled for October 27.” It has published no CVE, description or severity for that bug. Open-source users have nothing to apply until then. Watch the LiteLLM security advisories page that week and plan a maintenance window for the upgrade.

What to do now

1. Find every LiteLLM install. Check lockfiles, container base images, CI caches and developer laptops for 1.107.0 and for the floating Docker tags listed above.
2. Do not start Python on a suspect host. The issue reporter warned: “Don’t start with pip install . Any Python start in the affected environment runs cook.pth and sitecustomize.py again, and that includes running pip.”
3. Rebuild instead of cleaning. JFrog’s view is that “Rebuilding is safer than attempting to prove that every startup artifact, downloaded stage, and exposed secret was removed.” If you must clean in place, delete the three files, their __pycache__ copies and both /tmp markers with shell tools, kill the detached daemon, and only then reinstall.
4. Pin 1.106.2 explicitly, by digest for Docker images, never by a floating tag. JFrog’s advice is to pin it “only after removing the startup hooks or from a newly built clean environment.”
5. Rotate every credential the host could reach. Start with each provider key stored in the LiteLLM database, the LiteLLM master and virtual keys, and the database password. Then move to cloud roles, SSH keys, GitHub and package-publishing tokens. Revoke old keys at the provider; deleting them from LiteLLM does not stop a copied key working. Our guide to protecting API keys and tokens covers setting up the replacements.
6. Look for use from outside. Check provider dashboards for unfamiliar models or spend spikes, and cloud audit logs for your instance role being used from addresses you do not own. Our walkthrough on how to check if your application secrets were leaked lists where to look.
7. Patch or block the KEV-listed bugs. Run a clean release at or above 1.84.0, such as 1.106.2, and block the two MCP test endpoints at your reverse proxy if anything older is still running.

If this order of work feels familiar, it is close to what Railway users faced the same day in an unrelated incident. Our Railway rotation checklist and the GhostAction campaign show how often AI keys are what attackers hunt for. For its part, BerriAI says it has “made our docker release tags immutable, and are signing docker images.”

Frequently Asked Questions

Is LiteLLM 1.107.0 safe to keep if my proxy seems to work normally?

No. Researchers at SafeDep and JFrog found a credential stealer and an hourly remote-code loader in the 1.107.0 release, and neither changes how the proxy behaves. Treat any host or image that ran it as compromised, rebuild it, and rotate the secrets it could reach.

Which LiteLLM version should I run right now?

BerriAI told open-source users to pin 1.106.2 or another explicit version published before the bad release. SafeDep also found 1.106.2 clean. It is a later release than 1.84.0, the newest fixed version for the three KEV-listed CVEs; if you pinned an older version instead, check it against those fixes.

What is LiteLLM CVE-2026-42271?

It is a command injection flaw in two MCP test endpoints of the LiteLLM proxy. Any authenticated user, even one holding a low-privilege internal key, could run commands on the host. It was fixed in 1.83.7, and CISA lists it in its Known Exploited Vulnerabilities catalog.

Is the LiteLLM 1.107.0 compromise a CVE?

No. It is a supply-chain incident: a tampered release was published to PyPI and Docker registries. The three KEV-listed CVEs are separate code flaws with their own fixed versions.

What is the LiteLLM fix scheduled for October 27?

BerriAI says it is shipping an embargoed release to enterprise customers through a private registry for a vulnerability it plans to disclose on October 27. No CVE number, description or severity has been published.

Sources

• CVE-2026-42271 — NIST National Vulnerability Database (API record), published May 8, 2026 (last modified July 15, 2026)
• CVE-2026-42208 — NIST National Vulnerability Database (API record), published May 8, 2026
• CVE-2026-59822 — NIST National Vulnerability Database (API record), published July 8, 2026
• CISA Catalog of Known Exploited Vulnerabilities — CISA (Known Exploited Vulnerabilities catalog, JSON feed), October 21, 2026 (catalog version)
• Authenticated command execution via MCP stdio test endpoints — BerriAI / LiteLLM (GitHub Security Advisory GHSA-v4p8-mg3p-g94g), May 2026
• Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor — SafeDep (Kunal Singh), October 21, 2026
• LiteLLM Hijacked Again: Malicious 1.107.0 Wheels Steal Credentials and Load Remote Code — JFrog Security Research (Guy Korolevski), October 21, 2026
• [SECURITY] litellm 1.107.0 compromised (PyPI removed; Docker latest/main-stable removed) — BerriAI / LiteLLM GitHub issue #47826 (reporter and maintainer comments), October 21, 2026

This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.