Your AI gateway holds every provider key you have. A 9.9 just landed in LiteLLM.
An AI gateway concentrates every upstream key into one process. That is the point of it, and it is why a privilege escalation there is worse than it looks.
- Critical advisory
- GHSA-7hp6-4w63-5g45, CVSS 9.9, published 30 September 2026
- Effect
- internal_user escalates to proxy_admin, then remote code execution
- Patched in
- 1.100.4, 1.101.3, 1.102.2, 1.103.1, 1.104.0rc2
- Also
- GHSA-g5ff-637f-6q2m, CVSS 8.1, arbitrary file read, fixed in 1.95.0
- And
- GHSA-hhww-mrg2-969h, reflected XSS, fixed in 1.85.0
- CVE ids
- None assigned to any of the three
What the critical one does
The advisory is blunt: "An authenticated user with internal_user privileges can escalate to proxy_admin and achieve remote code execution." It is rated 9.9, which is about as high as a flaw requiring authentication gets.
The root cause is a design error rather than a coding slip. In the advisory's words, "The proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens." Because the same key does both jobs, a low-privilege user can get the proxy to encrypt attacker-chosen admin metadata as though it were a secret, then present the result back as a bearer token. The proxy decrypts it, believes the forged admin identity, and grants full administrative access, including command execution through the MCP stdio endpoint.
Every LiteLLM deployment has internal users. That is the ordinary role you hand to a developer or a team so they can use the gateway. The precondition here is not a sophisticated foothold, it is a normal account.
The patch for your line
LiteLLM maintains several release lines, so there is no single upgrade target. The advisory lists five affected ranges and five matching patched versions.
- 1.91.0 up to 1.100.4, patched in 1.100.4
- 1.101.0 up to 1.101.3, patched in 1.101.3
- 1.102.0 up to 1.102.2, patched in 1.102.2
- 1.103.0 up to 1.103.1, patched in 1.103.1
- 1.104.0rc1 up to 1.104.0rc2, patched in 1.104.0rc2
- Versions 1.87.0 through 1.90.x are exploitable only if EXPERIMENTAL_UI_LOGIN was explicitly set to true, so being below 1.91.0 is not automatically safe
The workaround has a price
If you cannot upgrade today, the advisory offers one mitigation: set EXPERIMENTAL_UI_LOGIN=false. It also says what that costs, and this part tends to get dropped in summaries: it "disables the vulnerable authentication path but also breaks CLI SSO and Claude Code gateway login".
So it is a real option, not a free one. If your developers sign in to the gateway through CLI SSO, flipping that flag at 6pm on a Friday trades a security problem for an availability one. Know which you are choosing.
The second one is worse than its rating suggests
A high severity advisory published 1 October, GHSA-g5ff-637f-6q2m at CVSS 8.1, lets an authenticated low-privilege user read arbitrary local files from the proxy runtime. The mechanism is a missed alias: the request-body safety blocklist rejected vertex_credentials but not vertex_ai_credentials, so a crafted value sent to the transform_request endpoint slipped through.
The advisory spells out where that leads: "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." In other words, a file read becomes the same outcome as the critical, by a different route.
There is no mitigation to fall back on here. The advisory says directly that no reliable configuration workaround exists on affected versions. The fix is 1.95.0.
A third advisory, a reflected cross-site scripting issue in the SSO debug callback, is rated moderate at 6.8 and fixed in 1.85.0. Its impact section mentions full admin account takeover, so the moderate label undersells it in prose. None of the three has a CVE assigned, which means a scanner keyed on CVE ids will not flag any of them.
Why upgrading is only half the job
This is the part teams skip, and it is the part that matters. Both the critical and the high end in exposure of the gateway's master key and the upstream provider keys it holds. If you were running an affected version and exposed to internal users, you should treat those secrets as potentially known.
An AI gateway is a deliberate concentration of credentials. You put it in front of your models precisely so that the OpenAI key, the Anthropic key, the Bedrock credentials and the rest live in one place with one access policy. That is good design, and it means the blast radius of a gateway compromise is every model vendor you use, not the gateway alone.
So the rotation list is longer than it first appears, and the order matters: rotate the things that let an attacker keep access before you rotate the things that merely cost money.
- Rotate LITELLM_MASTER_KEY first
- Rotate every upstream provider API key the proxy holds
- Reissue the virtual keys you have handed to teams and applications
- Review which accounts hold internal_user and whether they all still need it
- Check logs for requests to the transform_request endpoint carrying vertex_ai_credentials, and for hits on the SSO debug callback
- Look for key generation calls whose metadata contains admin role strings, followed by unexpected proxy_admin activity
What to do
- 1Upgrade to the patched version on your release line: 1.100.4, 1.101.3, 1.102.2, 1.103.1 or 1.104.0rc2.
- 2If you are on 1.87.0 to 1.90.x, check whether EXPERIMENTAL_UI_LOGIN was ever set to true.
- 3Rotate the LiteLLM master key, then every upstream provider key, then reissue virtual keys.
- 4If you must use the EXPERIMENTAL_UI_LOGIN=false workaround, know that it breaks CLI SSO and Claude Code gateway login.
- 5Upgrade to 1.95.0 or later for the file read issue, which has no configuration workaround.
- 6Search logs for transform_request calls carrying vertex_ai_credentials and for SSO debug callback hits.
Common questions
Which LiteLLM versions are affected by the critical advisory?
Five ranges: 1.91.0 to 1.100.4, 1.101.0 to 1.101.3, 1.102.0 to 1.102.2, 1.103.0 to 1.103.1, and 1.104.0rc1 to 1.104.0rc2. Patched in 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2 respectively.
Am I safe on a version below 1.91.0?
Not necessarily. The advisory says 1.87.0 through 1.90.x are exploitable if EXPERIMENTAL_UI_LOGIN was explicitly set to true. Versions later than 1.91.0 are exploitable in the default configuration.
What does the EXPERIMENTAL_UI_LOGIN=false workaround break?
The advisory says it disables the vulnerable authentication path but also breaks CLI SSO and Claude Code gateway login.
What should I rotate after patching?
The LiteLLM master key first, then every upstream provider API key the proxy holds, then the virtual keys issued to teams and applications. Both the critical and the high severity issue can disclose the master key and provider keys.
Is there a CVE for these?
No. All three advisories show no known CVE, so a vulnerability scanner that matches on CVE ids will not flag them. Match on the GHSA ids or on the version ranges instead.
Does the file read issue have a workaround?
No. The advisory states there is no reliable configuration workaround on affected versions. The fix is to upgrade to 1.95.0 or later.
Sources
- LiteLLM advisory: GHSA-7hp6-4w63-5g45 (critical)
- LiteLLM advisory: GHSA-g5ff-637f-6q2m (file read)
- LiteLLM advisory: GHSA-hhww-mrg2-969h (XSS)
- LiteLLM: all security advisories
Read against the primary documentation rather than secondary coverage. Where a figure comes from a provider's own docs, it is quoted as published on 2026-10-02.
Related
More from Signals
Open the tool.
Ten production categories, three minutes, and a ranked list of what to fix first.
Check your own stack