LiteLLM 1.18.10 contains a remote code execution vulnerability in its MCP server creation functionality. The application allows users to add MCP servers via a JSON configuration specifying arbitrary command and args values. LiteLLM executes these values on the host without validation, enabling attackers to run arbitrary operating system commands. Successful exploitation may result in remote code execution with the privileges of the LiteLLM process.

Impact

LiteLLM's /health/testconnection endpoint resolved request-supplied environment and OIDC file references in litellmparams. A proxy administrator, or another privileged caller with permission to test model connections, could cause LiteLLM to read files from the local filesystem via an oidc/file/ reference.

Because exploitation requires privileged proxy access, this is treated as a defense-in-depth issue rather than a cross-tenant privilege bypass.

Patches

The issue is fixed in 1.83.10-stable.

LiteLLM recommend upgrading to 1.83.10-stable or later.

Workarounds

Restrict /health/testconnection access to trusted administrators only.

Impact

LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.

The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object. This allowed requests with a fabricated Authorization header to reach MCP tooling without a valid LiteLLM key.

An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP.

Patches

The issue is fixed in 1.84.0.

We recommend upgrading to 1.84.0 or later.

Workarounds

If upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway.

References

v1.84.0

Impact

LiteLLM Skills archive extraction did not sufficiently validate file paths from uploaded skill ZIP archives. An authenticated user with access to LiteLLM LLM API routes, or a key whose allowedroutes includes /v1/skills, anthropicroutes, or llmapiroutes, could upload a crafted skill archive containing path traversal entries.

When the skill was processed for execution, those entries could be written outside the intended extraction/staging directory. This could allow arbitrary file write and may lead to code execution depending on deployment configuration and writable paths.

Patches

The issue is fixed in 1.83.7-stable.

LiteLLM recommens upgrading to 1.83.7-stable or later.

Workarounds

If upgrading is not immediately possible:

1. Block POST /v1/skills at your reverse proxy or API gateway. 2. Restrict Skills API access to trusted users only.

Impact

LiteLLM's Custom Code Guardrails production create/update paths did not apply the same sandboxing and validation used by the test endpoint.

A privileged user with access to create or update guardrails could submit custom Python code that executed in the LiteLLM proxy environment. In deployments without a configured master key, callers could be treated as proxy administrators, making this reachable without intended administrative authorization.

This could allow arbitrary code execution in the LiteLLM proxy container and exposure of secrets available to the process.

Patches

The issue is fixed in 1.82.0-stable.

LiteLLM recommend upgrading to 1.82.0-stable or later.

Workarounds

If upgrading is not immediately possible:

1. Restrict access to POST /guardrails and PUT /guardrails/{guardrailid} to trusted administrators only. 2. Ensure LITELLMMASTERKEY is configured. 3. Avoid enabling Custom Code Guardrails for untrusted users.

Hey everyone,

Seeing a lot of developers spinning up AI gateways lately, and I wanted to drop a technical heads-up about the LiteLLM command injection flaw (CVE-2026-42271) that CISA just added to the KEV catalog today.

If you are hosting LiteLLM for your org, you need to treat it like a highly sensitive asset. Here is a breakdown of how the exploit chain actually works and why it's so nasty.

The Exploit Chain Threat actors are chaining two distinct vulnerabilities to achieve zero-click Remote Code Execution:

1. Authentication Bypass (CVE-2026-48710): The vulnerability begins in the SSO integration layer. Attackers are manipulating JSON Web Token (JWT) headers during the OAuth callback phase. This allows an unauthenticated external attacker to forge a valid administrative session and bypass the login screen entirely. 2. YAML Command Injection (CVE-2026-42271): Once they have admin access, the attacker navigates to the model routing configuration panel. LiteLLM relies on Python libraries to dynamically parse YAML/JSON config files. The administrative API endpoints fail to sanitize user-supplied input before passing it to the OS shell. The attacker submits a malicious YAML string containing bash commands wrapped in template tags.

The Impact for SysAdmins The backend parser processes the YAML and executes the commands. Because many teams are deploying these gateways quickly in Docker containers running as root, the attacker gets an instant root shell on the host.

But the blast radius is massive. Because this gateway sits directly between your corporate apps and external AI models (OpenAI, Azure, Bedrock):

Stolen API Keys: The attacker can steal the master API billing keys stored in the database. Data Exfiltration: Every internal prompt (source code, financial data, HR records) passes through this gateway in plaintext. The attacker can silently mirror this traffic to an external C2 server, and traditional DLP won't catch it because the gateway is supposed to talk to external APIs.

Mitigation Steps

1. Patch immediately. The vendor has fixed the YAML sanitization. 2. If you can't patch, completely isolate the administrative dashboard behind a strict VPN or ZTNA. Do not rely on the built-in SSO. 3. Drop root privileges on your Docker containers. 4. If your admin panel was exposed to the web, assume breach and rotate ALL of your OpenAI/Azure API keys immediately.

Hope this helps some of you secure your environments before the weekend. Stay safe out there!

A security vulnerability has been detected in BerriAI litellm up to 1.82.2. Affected by this issue is the function uiviewusers of the file litellm/proxy/managementendpoints/internaluserendpoints.py of the component Incomplete Fix CVE-2025-0628. Such manipulation leads to improper authorization. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure.

A weakness has been identified in BerriAI litellm up to 1.82.2. Affected by this vulnerability is the function loadopenapispecasync of the file litellm/proxy/experimental/mcpserver/openapitomcpgenerator.py of the component MCP OpenAPI Spec Loader. This manipulation of the argument specpath causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.

A security flaw has been discovered in BerriAI litellm up to 1.82.5. Affected is the function asyncprecallhook of the file enterprise/enterprisehooks/bannedkeywords.py of the component Completions Interface. The manipulation of the argument prompt results in incorrect authorization. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure.

A vulnerability was identified in BerriAI litellm up to 1.82.2. This impacts the function getredirectresponsefromopenid of the file litellm/proxy/managementendpoints/uisso.py of the component SSO Authentication Flow. The manipulation leads to session expiration. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure.

A vulnerability was determined in BerriAI litellm up to 1.82.2. This affects the function json.dumps of the file litellm/proxy/managementendpoints/uisso.py of the component SSO Debug Flow. Executing a manipulation can lead to missing authentication. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure.

A security vulnerability has been detected in BerriAI litellm up to 1.82.2. Affected by this vulnerability is the function executewithmcpclient of the file litellm/proxy/experimental/mcpserver/restendpoints.py of the component MCP Server Connection Testing. The manipulation leads to server-side request forgery. Remote exploitation of the attack is possible. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure.

A weakness has been identified in BerriAI litellm up to 1.59.8. Affected is the function UserAPIKeyAuth of the file litellm/proxy/experimental/mcpserver/auth/userapikeyauthmcp.py of the component MCP Proxy. Executing a manipulation can lead to improper authentication. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure.

A security flaw has been discovered in BerriAI litellm up to 1.82.2. This impacts the function authenticateuser of the file litellm/proxy/auth/loginutils.py of the component PROXYADMIN database API Key Generator. Performing a manipulation results in session expiration. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure.

A vulnerability was identified in BerriAI litellm up to 1.82.2. This affects an unknown function of the file litellm/proxy/auth/userapikeyauth.py of the component M2M JWT Handler. Such manipulation leads to improper authorization. The attack can be launched remotely. A high complexity level is associated with this attack. The exploitability is reported as difficult. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure.

A vulnerability was determined in BerriAI litellm up to 1.63.1. The impacted element is an unknown function of the file litellm/proxy/managementendpoints/keymanagementendpoints.py of the component Admin Key Handler. This manipulation causes improper authorization. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. Patch name: 23781. It is recommended to apply a patch to fix this issue. The vendor was contacted early about this disclosure.

Impact

A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.

The auth layer derived the effective route from request.url.path in litellm/proxy/auth/authutils.py::getrequestroute(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.

Most deployments are not affected. The bypass is blocked by any upstream layer that validates or normalizes Host, such as:

- a CDN or WAF, such as Cloudflare - a reverse proxy with servername allowlists - a host-based load balancer

LiteLLM Cloud customers are not affected.

Patches

Fixed in 1.84.0. Upgrade to 1.84.0 or later. No configuration change is required.

Workarounds

If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the Host header before forwarding (a CDN/WAF, a reverse proxy with explicit servername allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.

References

- Patched release: v1.84.0

Discovery Credit: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)

LiteLLM prior to 1.83.10 allows a user to modify their own userrole via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxyadmin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the orgadmin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.

LiteLLM prior to 1.83.14 allows an authenticated internaluser to create API keys with access to routes that their role does not permit. When generating a key, the allowedroutes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internaluser to proxyadmin.

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.80.5 to before version 1.83.7, the POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. This issue has been patched in version 1.83.7.

BerriAI LiteLLM contains a command injection vulnerability that could allow any authenticated user, including holders of low-privilege internal-user keys, to run arbitrary commands on the host.

BerriAI LiteLLM contains a SQL injection vulnerability that allows an attacker to read data from the proxy's database and potentially modify it, leading to unauthorized access to the proxy and the credentials it manages.

LiteLLM through 2026-04-08 allows remote attackers to execute arbitrary code via bytecode rewriting at the /guardrails/testcustomcode URI.

Impact

The POST /guardrails/testcustomcode endpoint runs user-supplied Python inside a hand-rolled sandbox. The sandbox can be escaped using bytecode-level techniques, allowing arbitrary code execution in the proxy process — which runs as root in the default Docker image.

Reaching the endpoint requires a proxy-admin credential in default configurations.

Patches

Fixed in 1.83.11. The hand-rolled sandbox has been replaced with RestrictedPython. Upgrade to 1.83.11 or later.

Workarounds

If upgrading is not immediately possible, block POST /guardrails/testcustomcode at your reverse proxy or API gateway.

References

- Patched release: v1.83.10-stable

Hi,

Thank you Markus for posting this to oss-security on time.

On Thu, Apr 09, 2026 at 12:51:06AM +0200, Markus Vervier wrote: Workarounds ===========

No vendor patch is available at the time of publication. Users could apply the following mitigations: Somehow this section just ended with the above, without actually listing any mitigations. The copy of this advisory on the X41 website:

https://www.x41-dsec.de/lab/advisories/x41-2026-001-litellm/

actually includes the mitigations, which I'll copy-paste to here: - Block the endpoint at the reverse proxy level: If LiteLLM is deployed behind a reverse proxy such as nginx or Caddy, deny requests to /guardrails/testcustomcode. For example in nginx: location /guardrails/testcustomcode { deny all; return 403; }

- Restrict access to the admin API: The affected endpoint requires authentication with the master key. Ensure the master key is only known to trusted administrators and is not shared with regular API consumers.

- Do not expose the LiteLLM management interface to untrusted networks: Use network-level controls (firewall rules, VPC security groups) to limit access to the LiteLLM admin port to trusted hosts only.

- Avoid running LiteLLM as root: The default Docker image runs the process as root, maximizing the impact of code execution. Use --user to run the container as an unprivileged user to limit post-exploitation impact. Alexander

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enablejwtauth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, he /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to modify proxy configuration and environment variables, register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution, read arbitrary server files by setting UILOGOPATH and fetching via /getimage, and take over other privileged accounts by overwriting UIUSERNAME and UIPASSWORD environment variables. Fixed in v1.83.0.

Impact

When JWT authentication is enabled (enablejwtauth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters.

This configuration option is not enabled by default. Most instances are not affected.

An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled.

Patches

Fixed in v1.83.0. The cache key now uses the full hash of the JWT token.

Workarounds

Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.

Impact

The /config/update endpoint does not enforce admin role authorization. A user who is already authenticated into the platform can then use this endpoint to do the following:

- Modify proxy configuration and environment variables - Register custom pass-through endpoint handlers pointing to attacker-controlled Python code, achieving remote code execution - Read arbitrary server files by setting UILOGOPATH and fetching via /getimage - Take over other priveleged accounts by overwriting UIUSERNAME and UIPASSWORD environment variables

Patches

Fixed in v1.83.0. The endpoint now requires proxyadmin role.

Workarounds

Restrict API key distribution. There is no configuration-level workaround.