GHSA-g5ff-637f-6q2m: LiteLLM file read

Q: Is GHSA-g5ff-637f-6q2m actively exploited?

No confirmed active exploitation of GHSA-g5ff-637f-6q2m has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-g5ff-637f-6q2m?

1) Upgrade litellm to 1.95.0 or later (fix: PR 34189, commit 065faf6). 2) No reliable configuration workaround exists; as interim risk reduction, restrict network access to the proxy and disable SSO auto-provisioning of viewer accounts. 3) Rotate LITELLM_MASTER_KEY, provider API keys and any secrets in the proxy environment or on its filesystem if exposure is suspected. 4) Review proxy access logs for requests to /utils/transform_request containing vertex_ai_credentials from non-admin users. 5) Run the proxy as an unprivileged user in a minimal container with no unnecessary mounted secrets, and alert on anomalous use of provider keys.

Q: What systems are affected by GHSA-g5ff-637f-6q2m?

This vulnerability affects the following AI/ML architecture patterns: LLM gateway/proxy, model serving, agent frameworks, multi-provider LLM routing.

Q: What is the CVSS score for GHSA-g5ff-637f-6q2m?

GHSA-g5ff-637f-6q2m has a CVSS v3.1 base score of 8.1 (HIGH).

CISO Take

LiteLLM proxy versions before 1.95.0 let any authenticated user, even a read-only internal_user_viewer, read arbitrary files from the proxy host by sending a crafted vertex_ai_credentials value to /utils/transform_request, because the request blocklist covered vertex_credentials but missed its alias. The CVSS is 8.1 (high), and the real danger is escalation: reading /proc/self/environ can disclose LITELLM_MASTER_KEY and upstream provider API keys, which hands the attacker full proxy-admin control and access to every connected LLM provider account. No public exploit, Nuclei template or KEV listing exists and EPSS is not yet available, but exploitation is low-complexity and the low-privilege role is obtainable via SSO on many deployments. LiteLLM sits in front of many organizations' model traffic and its package risk score is 79/100 with 50 other CVEs, so treat it as a high-value credential store. Upgrade to 1.95.0 or later now, since no reliable configuration workaround exists, and rotate the master key and provider keys on any exposed instance.

Sources:GitHub AdvisoryOpenSSFATLAS

What is the risk?

High. Network-exploitable, low complexity, needs only low privileges (CVSS 8.1, C:H/I:H). No known public exploit or KEV listing and EPSS is unavailable, so likelihood is moderate today, but the fix is public in the commit and PR, which makes reverse-engineering a working exploit easy. Exposure is highest where the proxy is internet-reachable or SSO auto-provisions viewer accounts. Impact is amplified because the proxy centralizes credentials for multiple LLM providers.

How does the attack unfold?

Initial Access

Attacker logs in to the LiteLLM proxy with a low-privilege internal_user_viewer account, often via SSO.

AML.T0012

Exploitation

Crafted vertex_ai_credentials value sent to /utils/transform_request bypasses the blocklist and triggers a local file read.

AML.T0049

Credential Theft

Contents of /proc/self/environ are sent to an attacker-controlled URL, exposing the master key and provider API keys.

AML.T0055

Impact

Attacker uses the master key for full proxy-admin control and abuses connected LLM provider accounts.

AML.T0025

Initial Access

Attacker logs in to the LiteLLM proxy with a low-privilege internal_user_viewer account, often via SSO.

AML.T0012

Exploitation

Crafted vertex_ai_credentials value sent to /utils/transform_request bypasses the blocklist and triggers a local file read.

AML.T0049

Credential Theft

Contents of /proc/self/environ are sent to an attacker-controlled URL, exposing the master key and provider API keys.

AML.T0055

Impact

Attacker uses the master key for full proxy-admin control and abuses connected LLM provider accounts.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	< 1.95.0	`1.95.0`
62.0KOpenSSF 6.0Pushed 6d ago51% patched~47d to patchFull package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CHigh

IHigh

ANone

What should I do?

1 step

1) Upgrade litellm to 1.95.0 or later (fix: PR 34189, commit 065faf6). 2) No reliable configuration workaround exists; as interim risk reduction, restrict network access to the proxy and disable SSO auto-provisioning of viewer accounts. 3) Rotate LITELLM_MASTER_KEY, provider API keys and any secrets in the proxy environment or on its filesystem if exposure is suspected. 4) Review proxy access logs for requests to /utils/transform_request containing vertex_ai_credentials from non-admin users. 5) Run the proxy as an unprivileged user in a minimal container with no unnecessary mounted secrets, and alert on anomalous use of provider keys.

How is it classified?

Data ExtractionData LeakageAuth BypassAPIInferenceFrameworkAML.T0012- Valid Accounts AML.T0025- Exfiltration via Cyber Means AML.T0037- Data from Local System AML.T0049- Exploit Public-Facing Application AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to previously unknown risks and vulnerabilities

OWASP LLM Top 10

LLM02-Sensitive Information DisclosureLLM03-Supply Chain

Frequently Asked Questions

What is GHSA-g5ff-637f-6q2m?

LiteLLM proxy versions before 1.95.0 let any authenticated user, even a read-only internal_user_viewer, read arbitrary files from the proxy host by sending a crafted vertex_ai_credentials value to /utils/transform_request, because the request blocklist covered vertex_credentials but missed its alias. The CVSS is 8.1 (high), and the real danger is escalation: reading /proc/self/environ can disclose LITELLM_MASTER_KEY and upstream provider API keys, which hands the attacker full proxy-admin control and access to every connected LLM provider account. No public exploit, Nuclei template or KEV listing exists and EPSS is not yet available, but exploitation is low-complexity and the low-privilege role is obtainable via SSO on many deployments. LiteLLM sits in front of many organizations' model traffic and its package risk score is 79/100 with 50 other CVEs, so treat it as a high-value credential store. Upgrade to 1.95.0 or later now, since no reliable configuration workaround exists, and rotate the master key and provider keys on any exposed instance.

Is GHSA-g5ff-637f-6q2m actively exploited?

No confirmed active exploitation of GHSA-g5ff-637f-6q2m has been reported, but organizations should still patch proactively.

How to fix GHSA-g5ff-637f-6q2m?

1) Upgrade litellm to 1.95.0 or later (fix: PR 34189, commit 065faf6). 2) No reliable configuration workaround exists; as interim risk reduction, restrict network access to the proxy and disable SSO auto-provisioning of viewer accounts. 3) Rotate LITELLM_MASTER_KEY, provider API keys and any secrets in the proxy environment or on its filesystem if exposure is suspected. 4) Review proxy access logs for requests to /utils/transform_request containing vertex_ai_credentials from non-admin users. 5) Run the proxy as an unprivileged user in a minimal container with no unnecessary mounted secrets, and alert on anomalous use of provider keys.

What systems are affected by GHSA-g5ff-637f-6q2m?

This vulnerability affects the following AI/ML architecture patterns: LLM gateway/proxy, model serving, agent frameworks, multi-provider LLM routing.

What is the CVSS score for GHSA-g5ff-637f-6q2m?

GHSA-g5ff-637f-6q2m has a CVSS v3.1 base score of 8.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

LLM gateway/proxymodel servingagent frameworksmulti-provider LLM routing

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0025Exfiltration via Cyber Means

AML.T0037Data from Local System

AML.T0049Exploit Public-Facing Application

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM02, LLM03

What are the technical details?

Original Advisory

## Summary An authenticated LiteLLM proxy user could read arbitrary local files from the proxy runtime by sending a crafted `vertex_ai_credentials` value to `/utils/transform_request`. The request-body safety blocklist rejected `vertex_credentials` but missed its alias `vertex_ai_credentials`, which let the value reach the Vertex AI credential loader and trigger a file read that is sent to an attacker-controlled URL. ## Impact A low-privilege authenticated user (only `internal_user_viewer`, obtainable through SSO login on many deployments) could read any file readable by the LiteLLM process. Reading files such as `/proc/self/environ` can disclose `LITELLM_MASTER_KEY` and provider API keys, so the impact can escalate to full proxy-admin control. ## Remediation Upgrade to `1.95.0` or later. The fix adds the missing alias to the request-body blocklist, so no configuration change is needed once you upgrade. There is no reliable configuration workaround on affected versions.

Exploitation Scenario

An attacker signs in to a company's LiteLLM proxy through SSO and is automatically given the internal_user_viewer role. They send a request to /utils/transform_request with vertex_ai_credentials set to a local path such as /proc/self/environ and an attacker-controlled URL, so the Vertex AI credential loader reads the file and sends its contents there. The leaked environment includes LITELLM_MASTER_KEY and provider API keys. The attacker then authenticates as proxy admin, mints new keys, siphons prompts and responses from logs, and abuses provider accounts at the victim's expense.

Weaknesses (CWE)

CWE-20Improper Input ValidationPrimary CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')Primary

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.