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
A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. This vulnerability allows users to specify the apibase parameter when making requests to POST /chat/completions, causing the application to send the request to the domain specified by apibase. This request includes the OpenAI API key. A malicious user can set the apibase to their own domain and intercept the OpenAI API key, leading to unauthorized access and potential misuse of the API key.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, This vulnerability is fixed in 1.84.0.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.74.2 to before version 1.83.7, two endpoints used to preview an MCP server before saving it — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process. The endpoints were gated only by a valid proxy API key, with no role check. Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host. This issue has been patched in version 1.83.7.
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.
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 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.
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.