GHSA-g5ff-637f-6q2mhighSecret exposure2026-10-27

GHSA-g5ff-637f-6q2m: LiteLLM let a read-only proxy user read any local file, including the master key, through vertex_ai_credentials

An authenticated LiteLLM proxy user with only the internal_user_viewer role, which many deployments hand out through SSO, could read any file the proxy can read by sending a crafted vertex_ai_credentials value to /utils/transform_request. Reading /proc/self/environ can reveal LITELLM_MASTER_KEY and provider keys, which means full admin control. Fixed in LiteLLM 1.95.0. A separate reflected XSS in /sso/debug/callback was fixed in 1.85.0.

01.

What it is

GHSA-g5ff-637f-6q2m (LiteLLM before 1.95.0): the request-body blocklist rejected vertex_credentials but not its alias vertex_ai_credentials, so the value reached the Vertex AI credential loader, which read a local file and sent it to an attacker-controlled URL.

The advisory says there is no reliable configuration workaround on affected versions; the fix adds the alias to the blocklist.

GHSA-hhww-mrg2-969h (LiteLLM 1.65.5 to before 1.85.0): the unauthenticated /sso/debug/callback endpoint put identity-provider fields into an inline script without HTML escaping, so a display name containing </script> could run JavaScript on the proxy origin. An attacker with an account on the same IdP could send the callback link to a logged-in admin and take over their session.

02.

How to check

Affected: litellm (PyPI) before 1.95.0 for the file read, and 1.65.5 to before 1.85.0 for the XSS.
You are most exposed if you run the LiteLLM proxy with SSO or other low-privilege user accounts.

03.

How to fix

Upgrade litellm to 1.95.0 or later.
If a viewer-level account you don't fully trust used an older proxy, rotate LITELLM_MASTER_KEY and the provider API keys in the proxy's environment.

pip show litellm | grep -i version
pip install -U 'litellm>=1.95.0'

04.

Sources

More advisories for this tool