Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to Master Key Exfiltration) — STAR Labs Pwn2Own Research

Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to (TL-2026-1540), also tracked as Race Against The Patch: The Evolution of Four Exploit Chains in LiteLLM, is a critical-severity software vulnerability, first published 2026-07-19. It has no confirmed attribution, affects BerriAI LiteLLM Proxy, maps to 18 MITRE ATT&CK techniques (T1041, T1059, T1068), and is covered by 9 detection rules and 19 indicators of compromise.

Key facts for TL-2026-1540

Threat ID
TL-2026-1540
Also known as
Race Against The Patch: The Evolution of Four Exploit Chains in LiteLLM
Severity
CRITICAL
Status
PATCHED
Category
VULNERABILITY
First published
2026-07-19
Last reviewed
2026-07-19
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
technology, artificial-intelligence, software-development, cloud-computing, enterprise
Target regions
Global
Detection rules
9
Indicators of compromise
19

Malware and tooling in Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

Malware and tooling: MCP stdio server (transport: stdio)

STAR Labs researchers (Shi Weiming, Bruce Chen) built four distinct exploit chains against successive BerriAI LiteLLM proxy releases (1.82.3, 1.83.7, 1.83.10, 1.83.14) for Pwn2Own Berlin 2026's Local Inference category: an unauthenticated RCE chain (DB-unavailability auth bypass + Jinja2 SSTI + custom-guardrail sandbox escape), a post-auth privilege-escalation chain (metadata field-nesting + prefix-matched route bypass to proxy_admin), an unauthenticated credential-harvesting flaw in the onboarding token endpoint, and a stored os.environ reference-resolution bug that exfiltrated the LiteLLM master key through the Langfuse passthrough route.

How Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to works

On May 29, 2026 STAR Labs (Shi Weiming, Bruce Chen) published 'Race Against The Patch,' detailing four exploit chains they developed against BerriAI's LiteLLM AI-gateway proxy while preparing for the Local Inference category at Pwn2Own Berlin 2026. Each chain targeted a different release train (1.82.3, 1.83.7, 1.83.10, 1.83.14) as BerriAI shipped fixes within 4-9 days of each report, forcing the researchers to repeatedly re-pivot before the live contest.

Chain 1 (v1.82.3) achieved unauthenticated remote code execution by first flooding DB-touching auth endpoints with fabricated API keys to exhaust LiteLLM's 10-connection Prisma pool. When `allow_requests_on_db_unavailable=True`, the resulting PrismaError caused the auth handler to fall back to an implicit PROXY_ADMIN identity without key validation. With admin privileges obtained for free, the attacker generated a new admin key and injected a Jinja2 Server-Side Template Injection payload into the `/prompts/test` endpoint's `dotprompt_content` field (e.g. `{{ cycler.__init__.__globals__.os.popen('id').read() }}`), which is rendered via `jinja_env.from_string(...).render(...)` without restricting Python object traversal. A parallel path abused a custom-code guardrail sandbox: coroutine objects leaked the real `__builtins__` via `cr_frame.f_builtins`, letting an attacker recover `__import__("os")` despite a denylist, achieving sandbox escape.

Chain 2 (v1.83.7) was a post-authentication privilege-escalation-to-RCE path. LiteLLM's premium-feature gate checked `allowed_passthrough_routes` only at the top level of a key's configuration, but the field was honored when nested inside the untyped `metadata` dict, bypassing the premium check entirely. A route-authorization gate then used naive prefix matching, so an entry of `/user` granted access to any `/user/*` path including ones that shouldn't be reachable. Combined with a missing field-level filter on the `/user/update` self-update endpoint, a low-privileged internal user could set their own `user_role` to `proxy_admin`, then create a malicious MCP stdio server (`python3 -c "<payload>"`) and trigger subprocess execution by invoking the server's health/test endpoint.

Chain 3 (v1.83.10) reused Chain 2's role-escalation primitives to add the built-in `default_user_id` (a proxy_admin account) to an attacker-controlled team, then exploited a completely unauthenticated `/onboarding/get_token` endpoint: given only a public `invite_link` UUID, it returned a JWT embedding the invitee's full API key and inherited role, with no authentication dependency at all. A user-object cache TTL of roughly 60 seconds meant the attacker had to wait for the team-membership update to propagate before the authorization check would recognize the added admin, after which the JWT could be decoded to recover a live proxy_admin API key and again used to spin up an RCE-capable MCP stdio server.

Chain 4 (v1.83.14) targeted the LiteLLM master key itself. The `AddTeamCallback.validate_callback_vars` validator accepted callback metadata values shaped like `os.environ/LITELLM_MASTER_KEY` and stored them verbatim in the database without validation. A prior patch (commit df75e79615, April 13) had blocked this exact env-variable-reference pattern for real-time request bodies via `initialize_standard_callback_dynamic_params`, but the storage path used by `/key/generate` metadata went through an entirely different, unpatched validator. By setting a key's Langfuse callback metadata to `"langfuse_secret_key": "os.environ/LITELLM_MASTER_KEY"` with `"langfuse_host": "https://httpbin.org"`, then sending a request to `/langfuse/anything`, LiteLLM resolved the environment reference to the actual master key and forwarded it inside a Basic-auth Authorization header to httpbin's echo endpoint, which reflected the header back in its response body — letting the attacker base64-decode it to recover the master key in plaintext. Notably, the actual Pwn2Own Berlin 2026 contest build (v1.83.14-stable.patch.3, used May 8) shipped WITHOUT the intended fix (commit f2f1e3a0ba), though a separate, unrelated change had blocked MCP server creation without a valid cookie session; the researchers adapted live by using the leaked master key to log into the LiteLLM WebUI, capture an authenticated session cookie, and create the MCP stdio server that way.

All four chains were reported to and patched by BerriAI within 4-9 days of disclosure. The article explicitly notes no CVE numbers were assigned to these four specific chains; it references two unrelated, separately-tracked LiteLLM vulnerabilities for context — CVE-2026-30623 (MCP stdio command injection, GHSA-v4p8-mg3p-g94g) and CVE-2026-42208 (pre-auth SQL injection in proxy API key verification, GHSA-r75f-5x8p-qvmc, CVSS 9.3, exploited in the wild against `litellm_credentials`/`litellm_config` tables within 36 hours of disclosure). LiteLLM was independently exploited by three separate teams at Pwn2Own Berlin 2026, each chaining trust-boundary bugs (including SSRF and code injection variants) against the proxy to reach root-level code execution, underscoring systemic risk in AI-gateway trust assumptions around database availability, metadata parsing, onboarding flows, and secret-reference resolution.

MITRE ATT&CK techniques used in TL-2026-1540

Exfiltration

T1041 Exfiltration Over C2 Channel

Execution

T1059 Command and Scripting Interpreter

Privilege Escalation

T1068 Exploitation for Privilege Escalation; T1078 Valid Accounts; T1548 Abuse Elevation Control Mechanism

Initial Access

T1078 Valid Accounts; T1190 Exploit Public-Facing Application

Discovery

T1087 Account Discovery; T1518 Software Discovery

Command and Control

T1102 Web Service

Credential Access

T1110 Brute Force; T1528 Steal Application Access Token; T1552 Unsecured Credentials

Defense Evasion

T1140 Deobfuscate/Decode Files or Information; T1211 Exploitation for Stealth

Collection

T1213 Data from Information Repositories

persistence

T1505 Server Software Component

Resource Development

T1587 Develop Capabilities

Reconnaissance

T1595 Active Scanning

Affected products and versions in Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

  • BerriAI — LiteLLM Proxy
    Vulnerable versions: 1.82.3; 1.83.7; 1.83.10; 1.83.14; 1.83.14-stable.patch.3
    Fixed in: post-1.82.3 with commits 3737d6a1f39d09019337b10190a2cd6d8e2d3d08 / d910a95661fce3cdd36f3b06c03ecf9c46c6457c / 0a1b4427a6c4ee07add32295e331bd0cf9cac572; post-1.83.7 with commit e6f18ce75b; post-1.83.10 with PR #26843; post-1.83.14 with commit f2f1e3a0ba

Remediation for Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

Patches

  • Commit 3737d6a1f39d09019337b10190a2cd6d8e2d3d08 — centralized auth handling, removed DB-unavailability admin fallback
  • Commit d910a95661fce3cdd36f3b06c03ecf9c46c6457c — Jinja2 SSTI fix on /prompts/test
  • Commit 0a1b4427a6c4ee07add32295e331bd0cf9cac572 — custom-code guardrail sandbox escape fix (GHSA-wxxx-gvqv-xp7p)
  • Commit e6f18ce75b — field-level authorization alignment between /user/update and metadata-gated routes
  • PR #26843 — session-level token verification for /onboarding/get_token invite links
  • Commit df75e79615 — blocked os.environ/ references in real-time request bodies
  • Commit f2f1e3a0ba — validate_no_callback_env_reference rejects os.environ/ references at Pydantic validation time (storage path)
  • PR #25343 / commit 7b7f304 — restricted MCP stdio command to an allowlist (CVE-2026-30623, GHSA-v4p8-mg3p-g94g)
  • v1.83.7 — parameterized queries fix for CVE-2026-42208 (GHSA-r75f-5x8p-qvmc)

Immediate actions

  • Upgrade LiteLLM proxy to the latest stable release incorporating all four chain fixes (post v1.83.14 with commit f2f1e3a0ba applied)
  • Set allow_requests_on_db_unavailable=False or ensure the DB-unavailability fallback path never grants an admin identity
  • Rate-limit and monitor auth-touching endpoints to prevent Prisma connection-pool exhaustion
  • Restrict or disable the /prompts/test dotprompt rendering endpoint in production, or sandbox Jinja2 rendering with a safe subset
  • Audit all API keys and teams for allowed_passthrough_routes set via nested metadata; enforce field-level authorization consistently between top-level and metadata paths
  • Rotate the LITELLM_MASTER_KEY and any callback secrets (Langfuse, etc.) that may have been referenced via os.environ/ patterns
  • Disable or require authentication on /onboarding/get_token and validate invite_link tokens at the session level
  • Reject os.environ/ style references in stored key/team metadata (not just real-time request bodies)

Workarounds

  • Set disable_error_logs: true as a temporary SQLi mitigation (CVE-2026-42208) pending upgrade
  • Disable allow_requests_on_db_unavailable entirely if uptime tradeoff is acceptable
  • Restrict LITELLM_MCP_STDIO_EXTRA_COMMANDS to the minimum required launchers

Longer-term hardening

  • Restrict MCP stdio server command values to an explicit allowlist of known launchers (npx, uvx, python, python3, node, docker, deno)
  • Require authenticated, cookie-bound sessions for all MCP server creation/test endpoints
  • Implement centralized, single-source-of-truth authorization checks instead of duplicated logic across endpoints
  • Add anti-automation / rate limiting on database-backed authentication paths
  • Periodic red-team exercises specifically targeting AI-gateway trust boundaries (metadata parsing, secret-reference resolution, passthrough routes)

Weaknesses (CWE) in Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

CWE-287, CWE-1336, CWE-284, CWE-269, CWE-306, CWE-522, CWE-863, CWE-89

Timeline of Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

  • LiteLLM v1.82.3 released; contains the DB-unavailability auth-bypass and Jinja2 SSTI flaws exploited in Chain 1.
  • Commit df75e79615 blocks os.environ/ reference resolution in real-time request bodies, but not in the /key/generate metadata storage path later abused in Chain 4.
  • LiteLLM v1.83.7 released, fixing CVE-2026-42208 (SQL injection) but introducing the metadata-nesting premium-gate bypass and prefix-match route authorization flaw exploited in Chain 2.
  • GHSA-r75f-5x8p-qvmc published disclosing CVE-2026-42208, pre-auth SQL injection in LiteLLM proxy API key verification (CVSS 9.3), credited to Tencent YunDing Security Lab.
  • GHSA-v4p8-mg3p-g94g published disclosing CVE-2026-30623, authenticated command execution via MCP stdio test/creation endpoints; fixed via PR #25343 restricting stdio commands to an allowlist.
  • CVE-2026-42208 observed exploited in the wild roughly 36 hours after disclosure, targeting litellm_credentials and litellm_config database tables.
  • Chain 2 (v1.83.7) field-level authorization fix landed via commit e6f18ce75b, roughly 5 days after the v1.83.7 release.
  • LiteLLM v1.83.10 released; STAR Labs pivots to Chain 3, chaining Chain 2 primitives with the unauthenticated /onboarding/get_token endpoint.
  • LiteLLM v1.83.14 released, containing the AddTeamCallback os.environ reference-resolution flaw exploited in Chain 4 via the Langfuse passthrough route.
  • Intended fix for Chain 4 (commit f2f1e3a0ba, validate_no_callback_env_reference) prepared, roughly 4 days after v1.83.14.
  • Chain 3 fixed via PR #26843, introducing session-level token verification for onboarding invite links, roughly 9 days after v1.83.10.
  • GHSA-wxxx-gvqv-xp7p sandbox-escape fix (commit 0a1b4427a6c4ee07add32295e331bd0cf9cac572) lands for the custom-code guardrail bypass used in Chain 1.
  • Pwn2Own Berlin 2026 (Local Inference category); the contest build v1.83.14-stable.patch.3 unexpectedly shipped without commit f2f1e3a0ba applied, so STAR Labs successfully re-exploited the master-key exfiltration path live, adapting around an unrelated MCP-cookie-auth change by logging into the WebUI with the leaked master key.
  • STAR Labs publishes 'Race Against The Patch: The Evolution of Four Exploit Chains in LiteLLM,' detailing all four chains, PoCs, and the patch race against BerriAI.
  • BerriAI discloses five additional, unrelated LiteLLM CVEs (CVE-2026-12770 through CVE-2026-12774) covering separate authentication-bypass and credential-storage weaknesses, patched in v1.83.7-stable and later.

Sources cited for Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

Threats related to Four Chained Exploit Paths in LiteLLM Proxy (Pre-Auth RCE to

Detection coverage for TL-2026-1540

As of 2026-07-19, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1540 across Splunk SPL, Microsoft KQL and Sigma, covering 19 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats