What happened
On October 27, 2026, BerriAI published GitHub Security Advisory GHSA-w4c7-34wj-hqm8 for LiteLLM. The advisory rates the issue Critical, with a CVSS v3 base score of 10.0. It affects LiteLLM proxy deployments running with an Enterprise license in versions earlier than 1.103.10, 1.104.8, 1.105.6, and 1.106.5. Those four versions are listed as patched releases for their respective release lines.
The flaw is in an Enterprise-only proxy path. According to the advisory, an unauthenticated request sent to any LLM route can cause the proxy to read a local file and send its contents to a URL chosen by the attacker. This is not merely an error disclosure: the attacker-controlled destination creates an exfiltration path from the proxy environment.
The advisory gives /proc/self/environ as an example of a sensitive file. Reading it can expose LITELLM_MASTER_KEY and provider API keys held in the process environment. The master key provides full administrative access to the proxy. In some configurations, BerriAI says, that access can subsequently permit arbitrary Python code execution as root. The advisory classifies the weaknesses under external control of a file name or path, exposure of sensitive information, missing authentication for a critical function, and server-side request forgery.
The scope distinction matters. Open-source LiteLLM deployments without a license are not affected, because the relevant code paths load only when an Enterprise license is active. For organizations unable to update immediately, the advisory recommends blocking or stripping POST bodies containing standard_callback_dynamic_params, gcs_path_service_account, callbacks, success_callback, or failure_callback at a WAF, ingress layer, or reverse proxy. It also recommends allowlisting proxy egress to configured provider endpoints, keeping the proxy off the public internet where possible, loading the master key from a secret manager rather than the process environment, and setting a separate LITELLM_SALT_KEY.
What the archive adds
This is a new vulnerability event, but it concerns the same gateway project as the earlier LiteLLM 1.107.0 supply-chain compromise and its containment report. Those notes describe a compromised package release; this advisory instead concerns remote exploitation of licensed proxy deployments.
Trend signal
This supports Agent security moves to runtime boundaries. The decisive protections described here are not prompt rules or model behavior: they are patch level, authentication at ingress, secret placement, and outbound network policy. A gateway holding credentials is an execution and authorization boundary, so its runtime configuration becomes part of the security model.
Why it matters
LiteLLM proxies centralize access to models and providers, which makes their credentials especially consequential. A compromise of the proxy process can expose both the administrative key used to control the gateway and the provider keys it uses to call underlying model services. The advisory’s unauthenticated attack path also means that a deployment reachable by an attacker has little room for an operational response after exploitation begins.
For AI teams, the immediate lesson is architectural rather than vendor-specific. A model gateway should not be treated as an interchangeable request router. It is a credential-bearing service with filesystem access, outbound network access, and often a privileged position between applications and model providers. Patch discipline, egress allowlists, restricted ingress, and independently managed secrets are practical controls that reduce the blast radius of this class of flaw.
What happens next
- Affected Enterprise deployments will move to one of the listed patched versions or add edge mitigations. (3 months, 80%). Watch for: release upgrades and revised proxy deployment guidance.
- Teams will tighten gateway egress policies after reviewing whether the service can reach arbitrary internet endpoints. (6 months, 65%). Watch for: provider-only allowlists and private ingress configurations.
Limits and uncertainty
The advisory establishes the affected version ranges, the Enterprise-license condition, the described file-read and exfiltration mechanism, and the vendor’s mitigations. It does not state how many deployments are exposed, whether exploitation has occurred in the wild, or which configurations permit the stated root-level code-execution outcome. It also does not quantify how commonly the named keys are stored in process environment variables. The risk assessment for any individual installation therefore depends on its version, license state, route exposure, secret handling, and outbound network rules.
Skill to build now
This week, make an inventory of model gateways that hold provider credentials and document four properties for each: deployed version, public reachability, where its administrative secret is loaded from, and which destinations it can contact. For LiteLLM Enterprise specifically, compare the version against the patched releases in the advisory, then test whether ingress can reject the named callback-related request fields and whether egress is limited to approved provider endpoints. This turns a patch check into a repeatable gateway security review.
Reader takeaway
A critical LiteLLM Enterprise proxy flaw can turn one unauthenticated request into credential exfiltration and, in some configurations, root-level code execution. Upgrade to the listed patched release for your version line, and treat ingress authentication, secret storage, and egress restrictions as immediate containment controls.
Open question
How many Enterprise proxies are internet-reachable with master and provider keys still available through their process environments?