CVE-2026-12774: SSRF in BerriAI litellm MCP Server – Patch Guidance & Detection

Technical summary

The vulnerability resides in the _execute_with_mcp_client function within litellm/proxy/_experimental/mcp_server/rest_endpoints.py. The MCP Server Connection Testing component fails to properly validate or sanitize user-supplied input when establishing outbound connections. An authenticated user can craft a malicious request that causes the litellm server to initiate HTTP requests to arbitrary destinations, including internal IP ranges, cloud metadata endpoints, or external attacker-controlled servers. The CWE-918 classification confirms this as a classic SSRF flaw where user input flows directly into HTTP client operations without adequate filtering.

Business impact

For organizations using litellm as a managed proxy for LLM API requests, this vulnerability enables credential theft and lateral movement. An attacker with proxy access could exfiltrate internal secrets by forcing the server to connect to attacker-controlled logging or data collection infrastructure. In cloud environments, SSRF can be chained to access instance metadata services (IMDSv1/v2), potentially leading to cloud credential compromise. Multi-tenant deployments and shared litellm instances face heightened risk if tenant isolation relies on network segmentation rather than cryptographic controls.

Affected systems

BerriAI litellm versions up to and including 1.82.2 are affected. The vulnerability is specific to the MCP Server integration in the experimental proxy module. Organizations should verify their deployed version and check whether the MCP Server feature is enabled or accessible. Verify the exact affected version range against the vendor advisory to confirm patch eligibility.

Exploitability

Exploitation requires authentication (PR:L in CVSS), meaning an attacker needs valid credentials or access to the litellm proxy. Public exploit disclosure has occurred, reducing the time-to-weapon for adversaries. However, the requirement for prior authentication prevents unauthenticated, remote exploitation. Risk is elevated in environments where proxy access is granted to third parties, contractors, or less-trusted internal teams. The experimental nature of the MCP Server component suggests many production deployments may not yet use this feature, narrowing the immediate affected population.

Remediation

Upgrade litellm to a patched version released after 1.82.2. Verify the exact patch version number in the official BerriAI security advisory or GitHub releases. Organizations unable to patch immediately should restrict network access to the litellm proxy to trusted internal networks only, disable the MCP Server feature if not actively used, and implement outbound firewall rules to prevent the litellm process from reaching sensitive internal systems or cloud metadata endpoints.

Patch guidance

Check the BerriAI litellm GitHub repository and official security advisories for the patched version number and release notes. Apply patches through your standard deployment mechanism (pip, container image rebuild, or package manager). After patching, validate that the MCP Server functionality is still available if required, and test that legitimate MCP Server connections continue to function. Document the patch application for compliance and audit purposes.

Detection guidance

Monitor outbound HTTP/HTTPS connections initiated by the litellm process to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), cloud metadata endpoints (169.254.169.254), or unexpected external domains. Inspect litellm proxy logs for unusual MCP Server connection attempts or error messages related to network connectivity. Correlate authentication events with subsequent outbound connection anomalies. In WAF or API gateway logs, look for requests to the /mcp_server or rest_endpoints paths with payloads designed to trigger SSRF behavior.

Why prioritize this

Although the CVSS score is MEDIUM (6.3), this vulnerability warrants accelerated patching because: (1) public exploit disclosure exists, (2) SSRF in proxy software enables privilege escalation and lateral movement, (3) cloud metadata exfiltration can lead to account takeover, and (4) the authentication requirement is often weak in proxy-as-a-service architectures. Organizations running multi-tenant or externally-accessible litellm instances should prioritize this remediation over lower-severity flaws.

Risk score, explained

The CVSS:3.1 score of 6.3 (MEDIUM) reflects network attack surface (AV:N), low attack complexity (AC:L), and authentication requirement (PR:L). The Confidentiality, Integrity, and Availability impacts are each rated as Low (C:L/I:L/A:L) because SSRF allows data exposure and system compromise but not direct denial of service or data destruction. The score underweights the real-world risk in multi-tenant and cloud environments where SSRF + metadata endpoint access can escalate to high-impact credential theft. Organizations should consider raising their internal priority above the baseline CVSS if they operate proxy infrastructure accessible to multiple tenants or less-trusted users.

Frequently asked questions