BerriAI has patched a maximum-severity vulnerability in the LiteLLM proxy that lets an unauthenticated attacker read a local file and send its contents to a server of the attacker’s choosing. The flaw affects only deployments running with an Enterprise license and is tracked as GHSA-w4c7-34wj-hqm8; no CVE identifier has been assigned yet.
How One Request Leaks the LiteLLM Master Key
The vulnerability scores 10.0 on CVSS v3.1. A single unauthenticated request to any LLM route can make the proxy read a local file and transmit it to an attacker-chosen URL.
Environment File Exposure of Provider API Keys
Reading the process environment file exposes LITELLM_MASTER_KEY along with the provider API keys the proxy stores. The master key gives full administrative access to the proxy. Stored provider keys give an attacker access to the upstream AI services the organization pays for.
Path From Admin Access to Root Code Execution
In some configurations, an attacker holding the master key can go further and run arbitrary Python as root. The extent of that outcome depends on how the proxy is deployed, and the source does not describe which configurations are affected.
Affected Versions and Fixed Releases
Only Enterprise-licensed deployments are vulnerable. Open source deployments that run without a license are not affected.
BerriAI shipped fixes on PyPI on October 27, one for each supported release line: 1.103.10, 1.104.8, 1.105.6 and 1.106.5. Deployments on any of those four lines have a matching patched build.
Karmasec and Compass Security Reported the LiteLLM Flaw
Dylan Ong of Karmasec and Cyrill Bannwart of Compass Security reported the flaw. No exploitation has been confirmed, and no public proof-of-concept exploit is known.
This advisory is separate from the LiteLLM 1.107.0 PyPI backdoor reported on October 22. That earlier incident involved a compromised package release; the current flaw is a vulnerability in the Enterprise proxy code, and the two should not be treated as the same event.
Mitigations Listed in the Advisory
For operators who cannot update immediately, the advisory describes several interim measures. They include blocking callback-related JSON keys at the web application firewall or reverse proxy, limiting outbound traffic to known LLM providers, keeping the proxy off the public internet, and rotating keys if exposure is suspected.
The outbound-traffic measure addresses the exfiltration step directly. Because the attack depends on the proxy sending file contents to an attacker-chosen URL, a proxy restricted to known provider destinations has less room to leak data even if the request reaches it.
Why AI Gateway Credentials Concentrate Risk
LLM proxies sit between applications and several model providers, so they typically hold credentials for all of them in one place. A flaw that exposes the environment file of such a component exposes every downstream account at once, in addition to the proxy’s own administrative control.
That concentration is the reason the vulnerability reaches the top of the severity scale despite the Enterprise-only scope. The affected population is limited by licensing, but within it a single request can expose the keys and the administrative interface together.
The absence of a CVE identifier means vulnerability scanners and asset inventories keyed to CVE numbers may not flag the issue until one is assigned. The GitHub security advisory number is the current reference for tracking it.
The affected-version list also shows how the vendor structured the fix. By issuing a separate patched build for each of four active release lines on the same day, BerriAI let operators stay on their current line instead of moving to a new one. The researchers’ names appear in the disclosure, which indicates coordinated reporting before the release. With no public proof of concept at the time of the advisory, the window in which details are known only to the reporters and the vendor may be short, since patch contents become visible once they are published to PyPI.
