LiteLLM GHSA-g5ff-637f-6q2m: a viewer account can read files off the proxy, upgrade to 1.95.0
- What happened
- LiteLLM published GHSA-g5ff-637f-6q2m on Oct 1, 2026: High, CVSS 8.1, arbitrary file read by an internal_user_viewer via /utils/transform_request.
- Why it matters
- A read-only account can reach the master key and provider API keys on versions before 1.95.0, and the advisory names no workaround.
- What to do
- Upgrade the proxy to 1.95.0 or later (and to a build patched for GHSA-7hp6-4w63-5g45), then rotate keys and audit internal user accounts.
Our verdict on LiteLLM stays conditional. It is still the strongest free default for one OpenAI-format API over many providers, but this advisory shows the condition is real: a viewer-level account on an unpatched proxy can read the files that hold your keys. Upgrade to 1.95.0 or later now.
What happened
LiteLLM's GitHub security advisory GHSA-g5ff-637f-6q2m, published October 1, 2026, rates the flaw High with a CVSS score of 8.1. No CVE has been assigned. We re-read the advisory page on October 27, 2026.
- Who can exploit it: an authenticated user holding only the internal_user_viewer role.
- Where: the /utils/transform_request endpoint.
- Root cause: the request-body blocklist rejected vertex_credentials but missed its alias, vertex_ai_credentials, which let the value reach the Vertex AI credential loader.
- Impact: the attacker can read any file readable by the LiteLLM process. Environment files can expose LITELLM_MASTER_KEY and provider API keys, which can escalate to full proxy admin control.
- Affected: versions before 1.95.0. Patched: 1.95.0.
- Workaround: none. The advisory states there is no reliable configuration workaround on affected versions, and no configuration change is needed once you upgrade.
Why it matters
This is the second LiteLLM advisory in two days. On September 30, 2026, GHSA-7hp6-4w63-5g45 (Critical, CVSS 9.9) described a privilege escalation to proxy admin by an authenticated internal_user, caused by reusing one key for sealing secrets and for session tokens.
Both need only a low-privilege authenticated account. Your exposure therefore scales with two numbers: how many people hold keys on your proxy, and how long you run an old build. A gateway that sits in front of every provider key is the worst place to have a read-anything bug.
What changes for you
- Upgrade to 1.95.0 or later. That closes this file read.
- Check the other advisory too. 1.95.0 alone does not cover GHSA-7hp6-4w63-5g45, which affects 1.91.0 up to 1.100.4 (plus several later release lines). Its patched builds are 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2.
- Rotate secrets if any internal_user_viewer account was shared or untrusted on an affected build: the master key and every provider key the process could read.
- Audit internal accounts. Remove viewer and internal users who do not need access.
- Pin versions and patch within days. That is the discipline our conditional verdict assumes.
We have not deployed LiteLLM ourselves, so this is a reading of the advisories, not a reproduction.
What to do
- 1 Upgrade the LiteLLM proxy to 1.95.0 or later.
- 2 Confirm your build is also patched for GHSA-7hp6-4w63-5g45 (1.100.4, 1.101.3, 1.102.2, 1.103.1 or 1.104.0rc2 lines).
- 3 Rotate the master key and provider API keys if untrusted internal accounts existed on an affected build.
- 4 Remove internal and viewer accounts that do not need access.
Affected tools & models
Never need to catch up again
The weekly delta: only verdict changes and act-now items. No digest filler.