A critical Server-Side Request Forgery (SSRF) vulnerability designated as CVE-2026-59823 (CVSS score 9.1) in LiteLLM—a widely deployed proxy gateway for managing 100+ LLM APIs—allows attackers to manipulate backend routing and exfiltrate cloud credentials from AWS, GCP, and Azure metadata endpoints.

Executive Threat Summary

LiteLLM has become an essential abstraction layer in modern enterprise AI stacks, standardizing API requests to OpenAI, Anthropic, Bedrock, and self-hosted models while providing load balancing, cost tracking, and rate limiting. Enterprise environments routinely deploy LiteLLM inside internal VPCs with elevated cloud IAM roles to communicate with Amazon Bedrock, Vertex AI, and Azure OpenAI Service.

The discovery of CVE-2026-59823 demonstrates how AI gateway infrastructure can be turned into an initial compromise conduit. When an attacker is able to pass custom routing parameters or interact with misconfigured proxy instances, LiteLLM's HTTP forwarding engine can be directed toward sensitive internal network infrastructure.

Vulnerability Mechanics: IP Filter Bypass in Custom Model Endpoints

LiteLLM allows administrators and permitted users to register custom OpenAI-compatible endpoints by specifying an api_base URL. To prevent SSRF attacks against internal infrastructure, LiteLLM implemented a regular expression filter intended to drop loopback and RFC 1918 private IPv4 addresses.

However, the validation routine contained multiple parsing discrepancies:

  1. Hexadecimal and Decimal IP Encoding: The URL validator failed to normalize alternate IP representations, allowing addresses such as http://0x7f000001 or http://2130706433 (resolving to 127.0.0.1) to bypass filtering.
  2. DNS Rebinding Vulnerability: The proxy performed resolution only during configuration time rather than pinning the resolved IP at socket connection time, permitting time-of-check to time-of-use (TOCTOU) DNS rebinding attacks.
  3. IPv6 and Dual-Stack Loopback Omission: The validator did not properly evaluate IPv6 mapped IPv4 addresses ([::ffff:169.254.169.254]), leaving AWS and GCP metadata endpoints directly reachable.
# Vulnerable request routing example bypassing legacy regex filters
POST /v1/chat/completions HTTP/1.1
Host: litellm-proxy.corp.internal:4000
Authorization: Bearer test-key
Content-Type: application/json

{
  "model": "custom-model",
  "messages": [{"role": "user", "content": "ping"}],
  "api_base": "http://[::ffff:169.254.169.254]/latest/meta-data/iam/security-credentials/"
}

Blast Radius: From Proxy SSRF to Cloud Takeover

Because LiteLLM frequently runs on EC2 instances or EKS pods with attached IAM roles granting administrative or broad cloud access, an SSRF condition allows attackers to:

  • Harvest temporary STS credentials from the AWS Instance Metadata Service (IMDSv1 or IMDSv2 via header forwarding).
  • Access Google Cloud Workload Identity or GCP metadata access tokens via http://metadata.google.internal.
  • Scan internal Kubernetes service meshes, querying unprotected etcd, Prometheus, or internal vector databases (Milvus, Qdrant, Pinecone).

Vulnerability Profile & Impact Matrix

Characteristic Vulnerability Specification
Tracking Identifier CVE-2026-59823 / GHSA-338w-5282-998x
Weakness Class CWE-918: Server-Side Request Forgery (SSRF)
CVSS v3.1 Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N (Score: 9.1)
Affected Software LiteLLM prior to version 1.52.2
Remediated Software LiteLLM version 1.52.2 and above
Required Mitigation Upgrade package + Enforce AWS IMDSv2 Hop Limit 1

Remediation Checklist & Hardening Guidance

Organizations utilizing LiteLLM as an internal AI proxy should immediately apply the following mitigations:

1. Upgrade to LiteLLM v1.52.2

# Upgrade LiteLLM proxy container
docker pull ghcr.io/berriai/litellm:main-v1.52.2
docker stop litellm && docker rm litellm
docker run -d --name litellm -p 4000:4000 ghcr.io/berriai/litellm:main-v1.52.2 --config /app/config.yaml

# Pip package upgrade
pip install --upgrade litellm>=1.52.2

2. Enforce IMDSv2 with Hop Limit 1

Mitigate metadata exfiltration from containerized workloads by enforcing IMDSv2 and setting the HTTP hop limit to 1: 

# AWS CLI: Hardening EC2 instance metadata configuration
aws ec2 modify-instance-metadata-options     --instance-id i-0123456789abcdef0     --http-tokens required     --http-put-response-hop-limit 1     --http-endpoint enabled

3. Restrict Model Configuration Overrides

Configure litellm_settings to block dynamic api_base parameter overrides from client requests, ensuring endpoints are statically verified in config.yaml only.