CVE-2026-12798: litellm SSRF Vulnerability in MCP OpenAPI Spec Loader

Technical summary

The vulnerability exists in the load_openapi_spec_async function within litellm/proxy/_experimental/mcp_server/openapi_to_mcp_generator.py. By supplying a malicious spec_path argument, an attacker with valid credentials can trigger Server-Side Request Forgery (CWE-918), allowing the litellm server to initiate requests to arbitrary URLs. This could be leveraged to access internal services, cloud metadata endpoints, or external systems that the server can reach but the attacker cannot directly access.

Business impact

Organizations running litellm as a proxy or integration layer face potential data exposure if internal services are accessible via SSRF. Attackers with valid application credentials could enumerate internal infrastructure, exfiltrate sensitive configuration, or pivot to downstream systems. In multi-tenant or shared infrastructure environments, this could compromise isolation boundaries. The authentication requirement reduces the attack surface compared to unauthenticated SSRF, but credential compromise—either through phishing, supply chain, or other means—remains a realistic threat vector.

Affected systems

litellm versions up to and including 1.82.2 are affected. The vulnerability is specific to the MCP (Model Context Protocol) OpenAPI Spec Loader experimental feature. Deployments using litellm as a proxy service, especially those exposing the openapi_to_mcp_generator functionality, are most at risk. Verify your installed version against vendor advisories to confirm exposure.

Exploitability

The vulnerability is rated CVSS 6.3 (Medium) and has low attack complexity—it requires only a valid authentication context and network access to the litellm server. Public exploit code is available, increasing the likelihood of opportunistic attacks once credentials are obtained. The authentication requirement is the primary barrier; organizations with strong credential hygiene and network segmentation will see reduced practical risk, but patching remains important given the public availability of exploitation techniques.

Remediation

Upgrade litellm to a version beyond 1.82.2 that includes the SSRF fix. Verify the specific patched version number in the official BerriAI repository or security advisory. Until patching is possible, restrict access to litellm proxy endpoints to trusted internal networks only, limit the creation and distribution of authentication credentials for the service, and monitor outbound requests from the litellm process for suspicious destinations.

Patch guidance

Check the BerriAI litellm GitHub repository and official security advisories for the minimum patched version that addresses CVE-2026-12798. Apply patches in a staging environment first to verify compatibility with your proxy configuration and downstream integrations. Since the vulnerable component is experimental (MCP OpenAPI Spec Loader), verify whether your deployment actively uses this feature; if not, consider disabling it as a temporary mitigation. Ensure credential rotation policies are enforced after patching to invalidate any potentially exposed authentication tokens.

Detection guidance

Monitor litellm proxy logs for unusual outbound connection attempts, particularly to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata services (169.254.169.254). Track requests to the openapi_to_mcp_generator endpoint with spec_path parameters containing unexpected URLs or file:// schemes. Network-side detection should flag outbound requests from the litellm service to non-whitelisted destinations. Alert on failed authentication attempts followed by successful SSRF-pattern requests, which may indicate credential compromise followed by exploitation.

Why prioritize this

Although rated Medium severity, this vulnerability merits prompt attention because: (1) exploit code is publicly available; (2) it allows lateral movement or data exfiltration once credentials are obtained; (3) it targets a common architectural pattern (proxy services); and (4) the fix is straightforward patching. Prioritize patching in environments where litellm is network-accessible and where internal services lack additional authentication or IP-based access controls.

Risk score, explained

The CVSS 6.3 score reflects the combination of network accessibility (AV:N), low attack complexity (AC:L), the requirement for valid authentication (PR:L), single-target scope (S:U), and partial impact on confidentiality, integrity, and availability (C:L/I:L/A:L). The score is not elevated to 'High' because the login requirement creates a meaningful prerequisite, but the public exploit and ease of weaponization mean real-world risk may exceed the numeric score in threat-rich environments.

Frequently asked questions