> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# LiteLLM privilege escalation allows remote code execution via salt key reuse
- URL: https://f4n6.co.uk/security-feed/litellm-privilege-escalation-allows-remote-code-execution-via-salt-key-reuse/
- Published: 2026-10-27T15:37:10.000Z
- Updated: 2026-10-27T15:37:10.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

LiteLLM, the open-source LLM gateway proxy, reuses a single encryption key (the salt key) both to seal secrets at rest and to mint session tokens. An authenticated user holding only `internal_user` privileges can request a new API key with a crafted metadata field, receive the encrypted payload back, then present it as a bearer token; the proxy decrypts it, trusts the forged admin identity and grants `proxy_admin`, from which arbitrary commands can be run through the MCP stdio endpoint. Versions later than 1.91.0 are exploitable in the default configuration; 1.87.0 through 1.90.x are exploitable only when `EXPERIMENTAL_UI_LOGIN=true` is set. The GitHub advisory rates this High at CVSS v4 7.7 (AV:N/AC:L/AT:P/PR:L/UI:N, with High confidentiality, integrity and availability impact to the vulnerable system). No CVE has been assigned, there is no CISA KEV entry, and no EPSS score is available. For EMEA financial services the exposure is concentrated wherever LiteLLM fronts model access for internal teams: any low-privilege account, including a self-service or contractor key, becomes a route to host-level command execution and to the upstream provider credentials the proxy holds.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

## 3\. Technical analysis & attack chain

The flaw is a cross-domain key reuse: one encryption key serves two trust domains that should never share a secret. The proxy uses the salt key to encrypt stored secrets and also to sign or seal session tokens. Because the same key decrypts both, a value the attacker can get the proxy to encrypt as a "secret" is also a value the proxy will accept as a token.

Confirmed steps from the advisory:

1. The attacker authenticates to the LiteLLM proxy with an account that holds `internal_user` privileges.
2. The attacker requests a new API key, supplying a crafted metadata field whose "secret" value is a forged admin credential.
3. The proxy encrypts that value with the salt key and returns the ciphertext to the attacker.
4. The attacker presents the returned value as a bearer token.
5. The proxy decrypts it with the same salt key, trusts the forged admin identity inside it, and grants `proxy_admin`.
6. With proxy admin rights, the attacker executes arbitrary commands on the host through the MCP stdio endpoint.

The escalation is a privilege boundary failure (the advisory maps it to improper privilege management and to insufficient preservation of request origin). The end state is remote code execution on the proxy host, not merely administrative access to the proxy's own configuration. That distinction matters: the proxy host typically holds the operator's upstream provider API keys and sits on a network path to internal model endpoints, so host command execution reaches those secrets and that network position.

Affected versions, per the advisory: later than 1.91.0 are exploitable in the default configuration; 1.87.0 through 1.90.x are exploitable only if `EXPERIMENTAL_UI_LOGIN=true` was explicitly set. The advisory does not name the first patched version. It says only to upgrade to a patched version as soon as possible, so the exact fixed release must be confirmed against the BerriAI release notes before an upgrade is signed off. This is a gap in the source, not an omission here.

The interim mitigation is to set `EXPERIMENTAL_UI_LOGIN=false`. The advisory states this disables the vulnerable authentication path but also breaks CLI SSO and Claude Code gateway login, so it is a trade-off to plan for rather than a free fix.

Discovery is credited to Hoa X. Nguyen (OPSWAT Unit 515). The advisory does not state whether a public exploit exists. No proof-of-concept, exploit code or in-the-wild exploitation is described in the source, and none should be assumed.

Related LiteLLM issues in the same product, relevant because a single deployment often carries several of them at once:

- GHSA-r75f-5x8p-qvmc: SQL injection in proxy API key verification. An unauthenticated attacker sends a crafted `Authorization` header to any LLM API route (for example `POST /chat/completions`) and reaches the vulnerable query through the error-handling path, allowing read and possible modification of the proxy database and the credentials it manages. Fixed in 1.83.7; interim workaround is `disable_error_logs: true` under `general_settings`. Credited to Tencent YunDing Security Lab.
- GHSA-3cv6-jpf6-8222: authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters. Any authenticated proxy user can redirect an outbound provider call and cause the proxy to send its configured provider credentials to a destination the attacker controls, and can reach internal services from the proxy. Fixed across 1.88.6, 1.89.7, 1.90.7, 1.91.5, 1.92.2, 1.93.2, 1.94.3, 1.95.1 and 1.96.2; workaround is `general_settings.allow_client_side_credentials: false` plus blocking `api_base`, `base_url`, `model_list`, `fallbacks` and provider credential fields at the gateway.
- GHSA-5jmr-gcrj-2c9q: arbitrary file write via path traversal in Skills archive extraction. An authenticated user with access to LLM API routes, or a key whose `allowed_routes` includes `/v1/skills`, `anthropic_routes` or `llm_api_routes`, can upload a crafted skill ZIP with traversal entries that are written outside the staging directory, potentially reaching code execution. Fixed in 1.83.7-stable; workaround is to block `POST /v1/skills` at the reverse proxy.
- GHSA-4jcj-7x88-m979: improper authentication in the MCP Proxy (`UserAPIKeyAuth` in `litellm/proxy/_experimental/mcp_server/auth/user_api_key_auth_mcp.py`), affecting BerriAI litellm up to 1.59.8\. The advisory states an exploit has been made available to the public.

These related advisories are single-sourced to the GitHub Advisory Database entries cited in §7\. The version ranges above are as stated in each advisory; where a deployment's version sits between the ranges, confirm against the vendor release notes.

## 4\. Mitigation & containment

P1, within 24 hours:

- Inventory every LiteLLM proxy instance and record its version. Treat any instance later than 1.91.0 as exploitable by default, and any 1.87.0 through 1.90.x instance with `EXPERIMENTAL_UI_LOGIN=true` as exploitable.
- Where you cannot upgrade immediately, set `EXPERIMENTAL_UI_LOGIN=false` and accept that CLI SSO and Claude Code gateway login will stop working. Communicate that breakage to the teams using those paths before you flip it.
- Rotate the LiteLLM salt key and every upstream provider API key held by each proxy. The salt key is the shared secret behind this flaw; if an attacker already reached `proxy_admin`, assume the stored secrets are exposed. Rotating the salt key also invalidates any forged token minted under the old key.
- Review proxy audit logs for API key creation requests whose metadata carried an unexpected "secret" value, and for any `internal_user` account that subsequently acted with `proxy_admin` rights or invoked the MCP stdio endpoint. The advisory does not publish log field names, so scope this to key-creation and admin-action events you already record.

P2, within 72 hours:

- Upgrade to a patched release. The advisory does not name the fixed version, so confirm the target release against the BerriAI release notes before rollout, and pin it. Do not leave instances on a floating tag.
- If the deployment also runs an affected version of the related issues, bring it to at least 1.83.7 for the SQL injection and Skills traversal fixes, and to the matching fixed release for the SSRF issue. Set `disable_error_logs: true` under `general_settings` and `general_settings.allow_client_side_credentials: false` as interim controls where the upgrade lags.
- Block `POST /v1/skills` at the reverse proxy or API gateway unless the Skills API is in active use, and restrict it to trusted users if it is.
- Restrict who can hold `internal_user` keys on the proxy. The escalation needs only that baseline privilege, so self-service key issuance to broad populations widens the attack surface.

P3, within 7 days:

- Block the SSRF-relevant parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at the gateway for any instance not yet on a fixed release.
- Confirm the MCP stdio endpoint is reachable only from the proxy host and not exposed to users who do not need it. The advisory identifies it as the command-execution path once admin is obtained.
- Add the detection rules in §6 to proxy and host monitoring.

## 5\. Indicators of compromise

No indicators of compromise available in the source material.

The advisory describes a mechanism, not atomic artefacts: no hashes, domains, IPs, file paths or command strings are published. The observable behaviours below are derived from the described attack flow and are single-sourced to the GitHub advisory; verify against your own proxy logging before enforcing.

Behavioural indicators

| behaviour                                                                                 | where to observe                                                           | confidence                                             |
| ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------ |
| API key creation request carrying a forged admin credential in a metadata "secret" field  | LiteLLM proxy application and audit logs for key-management endpoints      | medium (mechanism described, no field names published) |
| internal\_user account presenting a bearer token that decrypts to an admin identity       | Proxy authentication logs; correlation of token issuance to privilege used | medium                                                 |
| internal\_user account acting with proxy\_admin rights shortly after a key-creation event | Proxy admin-action audit trail                                             | medium                                                 |
| Invocation of the MCP stdio endpoint by an account that was not previously admin          | Proxy and host process logs                                                | medium                                                 |

## 6\. Detection

The source gives no file artefacts, command strings, mutexes or registry keys, so a YARA rule would have nothing genuine to match and is not emitted. The usable material is behavioural: key-creation events and privilege transitions in the proxy. The Sigma rule below targets LiteLLM proxy audit events; field names vary by deployment, so map the `field` entries to your logging schema before deployment.

```yaml
title: LiteLLM internal_user privilege escalation via forged admin token
id: 8f3c2a10-6b7e-4d21-9a55-1c0e7d4b2f66
status: experimental
description: Detects a LiteLLM internal_user account creating an API key and then acting with proxy_admin rights, consistent with cross-domain salt key reuse escalation (GHSA-7hp6-4w63-5g45).
author: Adverse Trace
date: 2026-10-27
references:

  - https://github.com/advisories/GHSA-7hp6-4w63-5g45
logsource:
  product: litellm
  service: proxy
detection:
  key_creation:
    event_type: 'key_created'
  admin_action:
    event_type:

      - 'admin_action'
      - 'mcp_stdio_invocation'
  same_actor:
    user_role: 'internal_user'
  condition: key_creation and admin_action and same_actor
fields:

  - user_id
  - user_role
  - event_type
  - request_metadata
falsepositives:

  - Legitimate promotion of an internal_user to proxy_admin performed by an administrator
level: high

```

## 7\. Sources

- GitHub Security Advisories, "LiteLLM: Privilege Escalation to Proxy Admin via Cross-Domain Reuse of the Salt Key" (GHSA-7hp6-4w63-5g45), 2026-10-27\. https://github.com/advisories/GHSA-7hp6-4w63-5g45
- GitHub Security Advisories, "LiteLLM has SQL Injection in Proxy API key verification" (GHSA-r75f-5x8p-qvmc). https://github.com/advisories/GHSA-r75f-5x8p-qvmc
- GitHub Security Advisories, "LiteLLM: MCP Proxy Has Improper Authentication" (GHSA-4jcj-7x88-m979). https://github.com/advisories/GHSA-4jcj-7x88-m979
- GitHub Security Advisories, "LiteLLM: Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters" (GHSA-3cv6-jpf6-8222). https://github.com/advisories/GHSA-3cv6-jpf6-8222
- GitHub Security Advisories, "LiteLLM: Arbitrary file write via path traversal in Skills archive extraction" (GHSA-5jmr-gcrj-2c9q). https://github.com/advisories/GHSA-5jmr-gcrj-2c9q

## 8\. Adverse Trace position

Adverse Trace assesses this as High at CVSS v4 7.7, matching the GitHub advisory, with no CVE, no CISA KEV entry and no EPSS score to raise or lower that view; the exploitation precondition is an authenticated `internal_user` account, which most LiteLLM deployments hand out widely, and the outcome is host-level command execution, so the practical impact on a financial services client is higher than the base score alone suggests. The attribution is to a named independent researcher (Hoa X. Nguyen, OPSWAT Unit 515) for discovery; there is no threat-actor attribution and none should be inferred. The related LiteLLM advisories are single-sourced to the GitHub Advisory Database and should be verified against the vendor release notes before you pin versions. We will track the BerriAI release notes to identify the first patched version, since the advisory does not name it, and update this note when it is confirmed. Clients running LiteLLM as a shared gateway should treat salt key and provider credential rotation as the first action, ahead of the upgrade, because a forged token minted before the fix survives a patch until the key is changed.

---

[Read the original source →](https://github.com/advisories/GHSA-7hp6-4w63-5g45?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*