---
id: "GHSA-w4c7-34wj-hqm8"
page: "https://infrastack.ai/live/GHSA-w4c7-34wj-hqm8"
kind: "vulnerability"
aliases: ["GHSA-w4c7-34wj-hqm8"]
title: "Unauthenticated file read leaks master key on Enterprise proxy"
severity: "critical"
cvss: 10.0
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "litellm", "fixed": ["1.103.10"], "affected": "< 1.103.10", "ecosystem": "pypi"}, {"name": "litellm", "fixed": ["1.104.8"], "affected": "< 1.104.8", "ecosystem": "pypi"}, {"name": "litellm", "fixed": ["1.105.6"], "affected": "< 1.105.6", "ecosystem": "pypi"}, {"name": "litellm", "fixed": ["1.106.5"], "affected": "< 1.106.5", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "cwe-200", "cwe-306", "cwe-73", "cwe-918", "enterprise-license", "litellm", "python", "self-hosted"]
not_affected_if: ["managed-hosting", "open-source-no-license"]
published_at: "2026-10-27T20:33:15+00:00"
first_seen_at: "2026-11-09T22:53:22+00:00"
updated_at: "2026-11-09T22:54:05+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-w4c7-34wj-hqm8", "first_seen_at": "2026-11-09T22:53:22+00:00"}]
exploit_sources: []
---

# Unauthenticated file read leaks master key on Enterprise proxy

Link for people: https://infrastack.ai/live/GHSA-w4c7-34wj-hqm8 (this .md is for agents)

A LiteLLM proxy running with an Enterprise license can be made to read a local file, such as /proc/self/environ, and send its contents to an attacker-chosen URL. The leaked file exposes LITELLM_MASTER_KEY and provider API keys, giving the attacker full admin access to the proxy, and in some configurations arbitrary Python code execution as root.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:litellm affected < 1.103.10 fixed 1.103.10
- pypi:litellm affected < 1.104.8 fixed 1.104.8
- pypi:litellm affected < 1.105.6 fixed 1.105.6
- pypi:litellm affected < 1.106.5 fixed 1.106.5

## How to check

- Check the installed version with `pip show litellm` and compare it with the fixed versions below.
- Confirm whether the proxy runs with an Enterprise license; open source deployments without a license are not affected per the advisory.
- Check whether the proxy is reachable from the public internet.

## Fix

- `litellm` `1.103.10` on the 1.103 line
- `litellm` `1.104.8` on the 1.104 line
- `litellm` `1.105.6` on the 1.105 line
- `litellm` `1.106.5` on the 1.106 line

## Timeline

- 2026-11-09T22:53:22+00:00 ghsa-repo https://github.com/BerriAI/litellm/security/advisories/GHSA-w4c7-34wj-hqm8

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/BerriAI/litellm/security/advisories/GHSA-w4c7-34wj-hqm8

## From the sources

### Summary

An unauthenticated request to any LLM route on a LiteLLM 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 a file like `/proc/self/environ` exposes `LITELLM_MASTER_KEY` and provider API keys, which gives the attacker full admin access to the proxy. In some configurations, this allows the attacker to then execute arbitrary python code as root.

Open source deployments without a license are not affected, because the relevant codepaths only load when an Enterprise license is active. As defense in depth, we also recommend loading the master key from a secret manager instead of the process environment, setting a separate `LITELLM_SALT_KEY`, and limiting the proxy's outbound traffic to known provider endpoints.

### Mitigations
If you cannot update immediately, consider implementing the following:
* Block the trigger at the edge using a WAF, ingress filter, or reverse proxy rule: reject or strip POST request bodies that contain any of the JSON keys:
  * `standard_callback_dynamic_params`
  * `gcs_path_service_account`
  * `callbacks`
  * `success_callback`
  * `failure_callback`
* Restrict the proxy’s outbound network access to your configured LLM provider endpoints. The exploit requires the proxy to POST the stolen file contents to an attacker-controlled token endpoint; with egress allowlisted, the exfiltration fails even if the vulnerable code is reached.

Separately, we generally recommend keeping the proxy off the public internet where possible (e.g. via VPN, mTLS, an authenticating ingress, or an IP allowlist).


### Credit

Originally discovered and reported by Dylan Ong at Karmasec - https://karmasec.io/
Independently discovered and reported by Cyrill Bannwart - Compass Security

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_