LiteLLM's Enterprise Proxy Let Unauthenticated Requests Pick Where Failure Logs Went, Master Key Included

A request that LiteLLM’s proxy was about to reject could still decide where the record of that rejection was sent, and on Enterprise-licensed deployments that was enough to walk off with the proxy’s master key. BerriAI, the company behind LiteLLM, published the flaw as GHSA-w4c7-34wj-hqm8 at 20:33 UTC on October 27, 2026 (2:03 AM IST on October 28). The advisory carries a CVSS 3.1 score of 10.0, with network access, no privileges, no user interaction and a changed scope. No CVE identifier had been attached to it as of early October 29.

LiteLLM is an open-source gateway that puts one OpenAI-style API in front of many model providers and handles keys, budgets, rate limits and logging. That role is why the bug matters: the proxy’s environment holds the provider credentials routed through it.

From a rejected request to the process environment

The advisory’s summary is blunt. An unauthenticated request to any LLM route on a proxy running with an Enterprise license “could make the proxy read a local file and send its contents to a URL chosen by the attacker.” Reading /proc/self/environ exposes LITELLM_MASTER_KEY and the provider API keys, which BerriAI says gives “full admin access to the proxy,” and “in some configurations” lets an attacker execute arbitrary Python code as root.

The fix, pull request #48599, explains the mechanism. When the proxy turned a request away for a bad key, a rate limit, a budget or a guardrail, it built the failure log straight from the raw request body. That let a caller with no valid key steer the log to its own Langsmith or Langfuse host, and let a rejected request choose the Google Cloud Storage bucket and service-account file the GCS logger would use. The advisory adds that the exploit needs the proxy to POST the stolen file contents to an attacker-controlled token endpoint.

GitHub lists four weaknesses on the advisory: CWE-73 (external control of a file path), CWE-200 (information exposure), CWE-306 (missing authentication for a critical function) and CWE-918 (server-side request forgery).

Who is exposed, and who is not

The scope is narrower than LiteLLM’s install base. BerriAI states that open-source deployments without a license are not affected, “because the relevant codepaths only load when an Enterprise license is active.”

The patched versions span four release lines. The advisory marks anything below 1.103.10, 1.104.8, 1.105.6 or 1.106.5 as vulnerable on its respective line. PyPI timestamps show all four fixes uploaded between 19:39 and 19:44 UTC on October 27, roughly 50 minutes before the advisory went live. The 1.106.5 release notes describe the change only as keeping “core request fields, tags and guardrail details” in failure logs and making the GCS logger “use the bucket and credentials configured on the proxy,” with the note “No action needed to upgrade.” PyPI’s newest release is now 1.106.6.

The advisory credits two independent reporters: Dylan Ong of Karmasec, who found it first, and Cyrill Bannwart of Compass Security.

What the patch removes

Pull request #48599 is tagged as a breaking security fix, and it trims what rejected requests can carry. Failure logs now keep only model, messages, input, prompt, user, stream and litellm_call_id, plus tags and guardrail details from metadata. Tags are kept only after the key has authenticated. Request-time gcs_bucket_name and gcs_path_service_account values are ignored, and key and team attribution always comes from the authenticated key.

The pull request also flags a side effect: team-level loggers stop receiving failure logs for some rejections on routes such as rerank, image generation, moderations, audio and realtime.

Steps for Enterprise operators

• Upgrade to 1.106.5, 1.105.6, 1.104.8 or 1.103.10 depending on the line in use. Nothing older than 1.103.10 received a backport.
• If an upgrade has to wait, BerriAI recommends rejecting or stripping POST bodies that contain standard_callback_dynamic_params, gcs_path_service_account, callbacks, success_callback or failure_callback at a WAF, ingress or reverse proxy.
• Restrict the proxy’s outbound traffic to configured model-provider endpoints. Per the advisory, the exfiltration fails under an egress allowlist even if the vulnerable code is reached.
• If an Enterprise proxy was reachable from the internet, rotate the master key and every provider key it held.
• As defence in depth, load the master key from a secret manager instead of the environment, set a separate LITELLM_SALT_KEY, and keep the proxy behind a VPN, mTLS, an authenticating ingress or an IP allowlist.

No public reports of exploitation were found, and Writeble has not tested the issue. Because the fix shipped quietly ahead of the advisory, the risk now sits with licensed proxies that have not been upgraded since October 27.