LiteLLM's 9.9-Rated Chain Needs v1.83.14 to Close, and Two Dates for It Disagree

On a LiteLLM proxy running a release before v1.83.14-stable, an authenticated internal user holding an ordinary virtual key can write allowed_routes of /*, promote themselves to proxy_admin, and run code on the host. Obsidian Security rates the three-CVE chain 9.9, and Google's November 2 LLMJacking report separately tells defenders to patch LiteLLM, which is why the details matter for anyone who exposes a model gateway.

None of this needs a network foothold beyond a valid key. It does not cross into the vendor's hosted service; it concerns self-run proxies.

The three CVEs and what each needs

Obsidian's research, written by Fenix Qiao and published June 11 and updated September 7, lists the chain:

CVE	Flaw	Precondition
CVE-2026-47101	Key endpoints store caller-supplied allowed_routes unfiltered	A valid virtual key for a default internal_user
CVE-2026-47102	/user/update and /user/bulk_update let user_role be rewritten	org_admin, or internal_user after CVE-2026-47101
CVE-2026-40217	Custom-code guardrail runs code via exec() with __builtins__ exposed	Originally internal_user plus CVE-2026-47101; now proxy_admin

Obsidian gives one score, 9.9, for the full chain. The Hacker News reports that VulnCheck scored CVE-2026-47102 at 8.7 on CVSS 4.0 and 8.8 on CVSS 3.1. The score overstates the risk for operators who never gave users virtual keys, and understates it for teams that issue keys to every developer.

Why a patched proxy can still be a shell

Even after the fixes, Obsidian says registering a stdio MCP server requires proxy_admin but still enables command execution, and its tester reproduced a reverse shell on v1.88.0. So the practical control is who holds proxy_admin, not only the version.

Callbacks loaded from config.yaml under litellm_settings.callbacks "never appear in the admin UI," Obsidian notes, so a persistent implant there is invisible to a UI audit.

Two dates for the same release

Obsidian's timeline gives v1.83.10-stable on April 22 and v1.83.14-stable on April 25. The Hacker News says GitHub lists v1.83.14-stable as released May 2. The two sources conflict and this report does not pick a side; the practical instruction is the same, since both say version 1.83.14 or later contains the complete fix set.

Obsidian says it reported all three issues on February 19 by email and on Huntr. A first guardrail patch landed February 24 as PR #22095, and a regex deny-list in it was still bypassable. A public GitHub issue, #22205, was opened on February 26 to confirm receipt, and the author followed up April 1 after six weeks without a response. CVE-2026-40217 was published April 10, and VulnCheck assigned the other two on May 20.

The Google mismatch and exploitation status

Google's LLMJacking post cites CVE-2026-40217 as a user ID rebind flaw in /key/regenerate. Obsidian assigns that behaviour to the key-endpoint and role CVEs and describes 40217 as the guardrail sandbox escape. Read the label with care.

The Hacker News says Obsidian's chain has not been seen exploited in the wild. A different LiteLLM flaw, CVE-2026-42271, a stdio-MCP subprocess issue, was exploited and added to CISA's catalog in June, according to the same article. That is a separate record, and it shows attackers already look at this product. See also the GPUStack authentication bypass for a comparable model-serving case.

What to do

Upgrade to v1.83.14-stable or later. Audit who holds proxy_admin, review registered custom-code guardrails, and inspect litellm_settings.callbacks in config.yaml. If exposure is suspected, rotate provider API keys, database credentials and MCP tokens. Obsidian adds a warning against unknown third-party model relays, which can read or alter traffic from the same position an attacker would hold, a risk the Gemini reviewer-access page shows in another form.