LiteLLM Vulnerability GHSA-7hp6-4w63-5g45: Check Versions and Harden the Gateway

Running LiteLLM in your organisation? WZ-IT checks, updates and hardens LiteLLM gateways and takes over operation with CVE monitoring, see Managed LiteLLM and CVE monitoring. Book a meeting

On 30 September 2026, BerriAI published a security advisory for the LiteLLM proxy: GHSA-7hp6-4w63-5g45. An authenticated user with the internal_user role can escalate to proxy_admin and then execute arbitrary commands on the host through the MCP stdio endpoint. GitHub rates the flaw CVSS 9.9.

In many organisations, LiteLLM is the central access layer for language models: it bundles local models and provider APIs behind an OpenAI-compatible endpoint, manages keys and budgets, and holds the credentials of every connected provider for that purpose. Whoever takes over the gateway gains access to exactly those credentials. What LiteLLM does and where it sits in the stack is explained in What is LiteLLM?.

This article summarises how the flaw works, which versions are affected and patched, what the workaround costs in functionality, and which checklist secures a LiteLLM gateway beyond this case. All version information reflects 1 October 2026.

Table of Contents

1. The vulnerability at a glance
2. How the privilege escalation works
3. Affected and patched versions
4. Workaround if the update has to wait
5. What to check after possible misuse
6. LiteLLM vulnerabilities in 2026
7. Checklist: hardening a LiteLLM gateway
8. Our approach at WZ-IT
9. Further guides

The vulnerability at a glance

Source: GitHub Security Advisory GHSA-7hp6-4w63-5g45.

The vector describes a flaw that is exploitable over the network without user interaction and requires only low privileges. S:C (scope changed) means the impact extends beyond the attacked component: a user account in the gateway turns into code execution on the server.

How the privilege escalation works

The core of the problem is one key with two jobs. According to the advisory, LiteLLM uses the same key to encrypt stored secrets and to mint session tokens. The documentation calls this key LITELLM_SALT_KEY; among other things it encrypts the model provider credentials stored in the database (LiteLLM, Production Best Practices).

The sequence according to the advisory:

1. The attacker signs in with an account that has the internal_user role.
2. They request a new API key and place a forged admin credential in a metadata field as the supposed secret.
3. The proxy encrypts this value with the shared key and returns the result.
4. The attacker presents the encrypted value as a bearer token.
5. The proxy decrypts the token, trusts the forged admin identity and grants full administrative access.
6. As proxy_admin, the attacker can execute commands on the host through the MCP stdio endpoint.

This is a classic confused deputy pattern (CWE-441): the proxy becomes the tool that produces a valid token for the attacker. Nothing in the encryption itself is broken. The weakness is that data from two trust domains is protected with the same key and the proxy does not distinguish what a decrypted value was meant for.

proxy_admin is the highest role in LiteLLM, with full control over organisations, teams and users. internal_user can sign in, view their own keys and, depending on team permissions, create their own keys (LiteLLM, Access Control). The gap between these two roles is what the flaw bridges.

The MCP stdio transport starts a local process using command and args from the configuration (LiteLLM, MCP). That is intended for MCP servers, but it turns any ability to add or test stdio servers into command execution on the gateway host. Why MCP servers should generally be treated as code with their own privileges is covered in the article on the Model Context Protocol in organisations.

Affected and patched versions

The advisory distinguishes two cases: from version 1.91.0, the vulnerable path is active in the default configuration. In versions 1.87.0 to 1.90.x it is only active if EXPERIMENTAL_UI_LOGIN=true was explicitly set.

Sources: version ranges from the advisory, release dates from the LiteLLM releases. On 1 October 2026, 1.101.4 and 1.103.2 followed as further releases in these lines.

Three points that are easy to miss in practice:

• No backports for 1.91 to 1.99. Anyone running a version from these lines will not find a fix there. The affected range extends to below 1.100.4. This also applies to lines that received security updates for other flaws in August 2026.
• Docker images follow the same numbering. The official images are published at ghcr.io/berriai/litellm with tags such as v1.100.4. A tag such as main-latest says little about which version is actually running.
• Checking the version. The running version is shown by pip show litellm in the Python environment or by the litellm_version field in the response of /health/readiness. For containers, the image tag actually started is what counts, not the one intended in a compose file.

Versions before 1.87.0 are not affected by this flaw. They are, however, affected by other, partly actively exploited flaws (see LiteLLM vulnerabilities in 2026) and are not a safe state.

A second advisory appeared on the same day: GHSA-hhww-mrg2-969h, a reflected cross-site scripting flaw in /sso/debug/callback (CVSS 6.8) in versions 1.65.5 to below 1.85.0. Updating to one of the patched versions above also resolves it.

Workaround if the update has to wait

The advisory names one workaround: set the environment variable EXPERIMENTAL_UI_LOGIN=false. This disables the vulnerable authentication path. In LiteLLM's token check, this path is only skipped when the variable is explicitly set to false (litellm/proxy/auth/user_api_key_auth.py). A missing entry is not enough.

Teams that connect developer tools through the gateway should therefore plan the workaround as a short bridge: set it, restart the proxy, inform users, test and roll out the update, then reassess the variable deliberately.

What to check after possible misuse

The update closes the flaw but does not undo exploitation that has already happened. Whether it happened cannot be answered across the board. The review depends on who had access to accounts with the internal_user role and how long an affected version was running.

If misuse cannot be ruled out, clean-up includes:

• Rotate provider keys. A proxy_admin can use the stored model credentials, and command execution on the host also gives access to environment variables.
• Rotate the master key. LITELLM_MASTER_KEY is the admin credential for the API and the UI; LiteLLM documents a dedicated rotation flow for it (Production Best Practices).
• Change the salt key only with a plan. The documentation warns that changing LITELLM_SALT_KEY makes already encrypted credentials unreadable. A change therefore means re-entering all model credentials.
• Rebuild the host. If there are signs of command execution, a cleanly rebuilt container or host is more reliable than hunting for every single change.

Whether an incident has to be reported under GDPR or NIS2 depends on which data passed through the gateway and which systems were reachable from the host.

LiteLLM vulnerabilities in 2026

GHSA-7hp6-4w63-5g45 is not the first critical LiteLLM flaw this year. Three earlier flaws are listed in the Known Exploited Vulnerabilities catalog of the US agency CISA, meaning exploitation has been confirmed.

As of 1 October 2026; BerriAI maintains the full list under Security Advisories. In addition, there was the supply chain incident of 24 March 2026: the PyPI packages litellm 1.82.7 and 1.82.8 were compromised for around 40 minutes, triggered by a compromised Trivy dependency in the CI pipeline. According to BerriAI, the official Docker image was not affected (LiteLLM, Security Update March 2026).

Two conclusions for operations follow from this:

• MCP is the recurring attack surface. Two of the three exploited flaws and the current flaw involve MCP. Disabling MCP in the gateway when it is not needed reduces the attack surface considerably.
• The release cadence is high. LiteLLM publishes several releases per week and maintains several stable lines in parallel. Without a fixed update process, a gateway drops out of the patched range within a few weeks. How structured vulnerability monitoring for self-hosted software is set up is described in CVE monitoring for self-hosted software.

The Ollama flaw Bleeding Llama showed a similar pattern in spring: self-hosted AI components are only as secure as their operation. For n8n, which is often combined with LiteLLM, the article on the n8n security update September 2026 summarises the current advisories.

Checklist: hardening a LiteLLM gateway

The following checklist goes beyond the current flaw. It is aimed at operators who use LiteLLM as the central gateway for several teams or applications.

On the network segment: the common assumption that a gateway on the internal network is protected does not hold for this flaw. The attacker needs a valid user account, so they usually come from the internal network or through a compromised account. Network segmentation reduces the attack surface but replaces neither the update nor tight role assignment.

On MCP: an MCP server using the stdio transport is a process on the gateway host. Teams that provide MCP tools for agents should rather run them as separate services with HTTP transport in a separate segment and only allow them in the gateway, instead of starting arbitrary commands on the gateway itself. How agents work with limited permissions and approval steps is described in AI agents: permissions and approvals.

On provider choice: the gateway is also where you define which models are reachable at all. How European model APIs and your own inference are combined through LiteLLM is shown in the comparison of European LLM APIs.

Our approach at WZ-IT

WZ-IT operates LiteLLM as Managed LiteLLM with TLS, network segmentation, monitoring and fixed operating processes. For an advisory such as GHSA-7hp6-4w63-5g45, the work runs in five steps:

1. Determine exposure. Record the running version, image tag, environment variables and active login paths and compare them against the version ranges in the advisory.
2. Mitigate until the update. If needed, set EXPERIMENTAL_UI_LOGIN=false and coordinate the effect on CLI logins with users.
3. Apply the update. Check the patched version in a test environment, test routing, fallbacks, budgets and integrations, then roll it out to production.
4. Look for traces. Review roles, keys, MCP entries and logs for anomalies; rotate keys in a controlled way if misuse is suspected.
5. Harden and monitor continuously. Implement the checklist above and add the gateway to CVE monitoring, which evaluates vendor security advisories in addition to the NVD.

Alongside your own inference on the AI Cube or a managed GPU server from WZ-IT, the gateway can also connect European model APIs. Support, consulting and implementation by WZ-IT.

Further guides

• What is LiteLLM?, the role and structure of the gateway in the LLM stack.
• Model Context Protocol in organisations, how MCP works and which risks stdio servers bring.
• n8n security update September 2026, version matrix and hardening for n8n.
• Bleeding Llama (CVE-2026-7482), what the Ollama flaw shows about operating local AI.
• CVE monitoring for self-hosted software, how vulnerabilities are tracked in a structured way.
• European LLM APIs compared, combining providers behind one gateway.
• Langfuse for LLM observability, logging model calls in a traceable way.
• AI solutions from WZ-IT, the hub with all offerings for local AI and LLM operations.

Have your LiteLLM version checked? We compare your installation against the advisory, apply the update and harden the gateway according to the checklist. Book a meeting

Sources

• GitHub Security Advisory GHSA-7hp6-4w63-5g45, LiteLLM
• GitHub Security Advisory GHSA-hhww-mrg2-969h, LiteLLM
• LiteLLM, Security Advisories
• LiteLLM, Releases
• LiteLLM, Release v1.100.4
• LiteLLM, Release v1.101.4
• LiteLLM, Release v1.103.2
• LiteLLM, source code user_api_key_auth.py
• LiteLLM Docs, Production Best Practices
• LiteLLM Docs, Access Control
• LiteLLM Docs, MCP
• LiteLLM, Security Update March 2026
• CISA, Known Exploited Vulnerabilities Catalog
• NVD, CVE-2026-42208
• NVD, CVE-2026-42271
• NVD, CVE-2026-59822