LiteLLM File Read via vertex_ai_credentials and SSO Debug XSS: Upgrade to 1.95.0

LiteLLM versions before 1.95.0 let a user with only the internal_user_viewer role read any file the proxy process can read. GitHub rates GHSA-g5ff-637f-6q2m high (CVSS 8.1). Reading /proc/self/environ can expose the LITELLM_MASTER_KEY and provider API keys. A second, medium advisory, GHSA-hhww-mrg2-969h, covers reflected XSS on the SSO debug callback in versions 1.65.5 up to 1.85.0. Upgrade to 1.95.0 or later and both are fixed.

If a team routes Claude Code or other coding agents through a LiteLLM gateway, this matters because the proxy typically holds every provider key behind it. A file-read bug on that host is a key-theft bug. Neither advisory has a CVE ID at the time of writing, so searching only for CVE numbers will miss them. The tool's page in the Beam CVE database is LiteLLM.

Quick answers

The file read: what the advisory says

According to the GitHub advisory, published October 1, 2026 and updated October 27, an authenticated proxy user could send a crafted vertex_ai_credentials value to the /utils/transform_request endpoint. The weaknesses are classed as CWE-20 (improper input validation) and CWE-22 (path traversal). The vector is network, low complexity, low privileges, no user interaction, with high confidentiality and integrity impact.

The root cause is an incomplete blocklist. The proxy filters sensitive parameters out of request bodies, and the list included vertex_credentials. It did not include the alias vertex_ai_credentials. That alias flowed through to the Vertex AI credential loader, which treats a string value as a path to read from disk and, per the advisory, then sent the file contents to an attacker-controlled URL.

The attack chain, step by step

1. The attacker holds a proxy account. The lowest role is enough: internal_user_viewer, which is meant to be read-only.
2. They call /utils/transform_request with a request body that includes vertex_ai_credentials set to a file path on the proxy host.
3. The blocklist misses the alias. Because only vertex_credentials was blocked, the parameter reaches the provider code.
4. The Vertex AI credential loader reads the file. It reads whatever the proxy process can read.
5. The contents go to an attacker-controlled URL. The attacker chooses where the loaded data is sent.
6. The attacker reads /proc/self/environ, where a typical deployment keeps LITELLM_MASTER_KEY and provider API keys as environment variables. With the master key, the advisory notes the attacker can potentially gain proxy-admin control.

The pattern is a familiar one: a denylist guarding a parameter breaks the moment the same parameter has a second name. Allowlisting the fields a caller may set is sturdier than listing the ones they may not.

The SSO debug XSS: what the advisory says

The second advisory, GHSA-hhww-mrg2-969h, was published September 30, 2026 and credits the reporter InfosecShinobi. It affects litellm from 1.65.5 up to but not including 1.85.0, rated moderate at CVSS 6.8 and classed CWE-79. The fix is in 1.85.0 (the advisory references pull request #27498).

The /sso/debug/callback route placed identity-provider fields into an inline <script> block using json.dumps. As the advisory puts it, that "escapes JSON string syntax but not HTML context characters" such as a closing script tag. A value containing one can end the script block and start attacker markup.

1. The attacker has an account at the configured identity provider and sets a display name or similar field to a payload.
2. They complete the SSO flow against the proxy, which produces a callback URL carrying that data.
3. They send the URL to a logged-in proxy admin. The route itself needs no authentication, but the victim has to open the link.
4. Script runs in the proxy origin. It can read the dashboard session cookie or act with the admin's privileges, which can end in admin account takeover.

The attack complexity is rated high because the attacker needs both an IdP account the proxy trusts and a victim who clicks. That makes it a smaller risk for single-user deployments and a larger one for shared gateways with enterprise SSO.

Who is affected

Anyone running the LiteLLM proxy server from the pip package, or an image built from it, at the versions above. The Python SDK used purely as a client library does not expose the proxy endpoints, though the dependency should still be updated. The exposure grows with the number of accounts: every person or service key with a viewer role is a potential entry point for the file read, and any SSO-enabled proxy with several admins is a candidate for the XSS.

The file read is the more serious one. A viewer role is the one teams hand out freely for dashboards and spend reports, and the advisory shows it is enough to reach the host's environment. We found no report of exploitation in the wild for either advisory, and neither describes indicators of compromise.

What "no CVE" means for your scanners

Both advisories are reviewed GitHub advisories without a CVE ID, and the file-read entry was updated the same day this post went up. Dependency scanners that key on CVE numbers may stay quiet while the GHSA entries are live. Tools that consume the GitHub advisory database, such as Dependabot, pip-audit and OSV-based scanners, match on the package and version range instead, so run one against the proxy's lockfile or image. If your inventory only tracks CVEs, add these two GHSA IDs by hand until a CVE is assigned. Beam's beam cve check, covered in checking dependencies for known CVEs in CI, matches lockfiles against the Beam CVE database, and we have not confirmed that it lists these two entries. That is one more reason to verify the installed version directly with pip show litellm instead of trusting a single feed.

Why this keeps happening to gateways

LiteLLM has been in our coverage several times this month. The salt key reuse privilege escalation lets an internal user mint an admin token. The LiteLLM 1.107.0 PyPI and Docker compromise was a supply-chain attack on the same kind of AI credentials. These are different mechanisms with one target: the set of keys a gateway holds. The vLLM advisories show request-controlled parameters reaching sensitive code on the serving side too.

The Symantec report on agents abusing exposed AI endpoints explains why attackers look for these hosts, and the OpenRouter breach claim is another reminder that aggregated AI keys are a prize.

What this means if you run AI coding agents

1. Check the version. On the proxy host or inside the container, run pip show litellm and read the Version line. For container images, check the digest, not just the tag.
2. Upgrade to 1.95.0 or later. For example pip install --upgrade "litellm>=1.95.0", then rebuild images instead of patching running containers. The advisory says the fix needs no configuration changes.
3. Do not rely on a workaround. The advisory says there is no reliable configuration workaround on affected versions of the file read. Until you upgrade, limit who holds any proxy account, and restrict network access to the proxy admin and utility endpoints.
4. Review accounts and roles. Remove viewer accounts and keys you no longer use. A viewer key shared in a wiki or chat is now a path to the host.
5. Look for signs of abuse. The advisories give no indicators, so these are our suggestions: requests to /utils/transform_request containing a vertex_ai_credentials value from viewer accounts, outbound connections from the proxy to unfamiliar hosts, and unexpected admin sessions. For the XSS, check for SSO logins with unusual display names.
6. Rotate if you find anything, or if you cannot rule it out. Rotate the upstream provider keys the proxy holds, then the master key. Our runbook for the first 24 hours after a vendor breach covers the order.
7. Keep secrets out of the process environment where you can. The attack worked because /proc/self/environ held live keys. A secrets manager that injects short-lived values reduces what a file read yields, though the process can still read what it has loaded.
8. Serve the admin UI from its own origin if you can, and keep admins from opening SSO debug URLs sent by others. Disabling the debug route at your reverse proxy is a sensible hardening step, though the advisory only prescribes the upgrade.

What Beam can and cannot do here

Beam does not apply to the server-side bugs. It runs on a developer machine, watching what Claude Code, Codex and similar agents do, flagging risky actions such as credential exposure and destructive commands, and scanning skills and MCP configurations with its heuristics and a version-pin check. It does not inspect, patch or monitor a LiteLLM proxy.

The one modest overlap is client-side. If an agent session prints or writes the gateway key it uses, Beam's credential detection can flag it locally, and redaction runs before anything is stored. That does not stop a server-side file read. Detection is heuristic and on-device, and it is no substitute for upgrading. See how Beam keeps data local and what it watches.

Frequently asked questions

Which LiteLLM versions have the vertex_ai_credentials file read?

The advisory lists the litellm pip package before 1.95.0. Version 1.95.0 contains the fix and the advisory needs no configuration change to apply it.

Who can exploit the file read?

An authenticated proxy user, including one with only the internal_user_viewer role. The advisory scores it CVSS 8.1 (high) with low privileges required and no user interaction.

Is there a workaround if I cannot upgrade?

The advisory states there is no reliable configuration workaround on affected versions. Upgrade to 1.95.0 or later, and rotate keys if you suspect exposure.

How does the SSO debug XSS work?

The /sso/debug/callback page put identity-provider fields into an inline script block, escaping JSON syntax but not HTML characters like a closing script tag. A crafted display name can run script in the proxy origin when an admin opens the callback URL. It affects 1.65.5 up to 1.85.0.

Do these advisories have CVE numbers?

Not at the time of writing. Both are published as GitHub advisories (GHSA-g5ff-637f-6q2m and GHSA-hhww-mrg2-969h) without a CVE ID.

Can Beam detect or block this?

No. Beam runs on a developer machine and does not inspect or protect a LiteLLM server. It can flag credentials that an agent session exposes locally.

Related reading

• LiteLLM CVE-2026-114612: salt key reuse
• LiteLLM 1.107.0 PyPI and Docker compromise
• MCP security in practice
• API keys in logs and env vars
• Sources: GHSA-g5ff-637f-6q2m and GHSA-hhww-mrg2-969h on GitHub, and the LiteLLM repository

Versions and advisory details are accurate as of October 27, 2026. Check the linked advisories and LiteLLM's release notes for changes.