LiteLLM SSRF sinks expose cloud metadata and internal services

At a glance

What this is: This is an analysis of three SSRF sinks in LiteLLM, including user-reachable and admin-reachable paths that can reach loopback and cloud metadata destinations.

Why it matters: It matters because LLM gateways often run inside trusted cloud networks, so SSRF becomes an identity and access problem as much as an application security flaw.

Context

SSRF becomes especially dangerous when the affected service is designed to make outbound requests on behalf of users. In an LLM gateway, that pattern can turn untrusted input into server-side access to cloud metadata, loopback services, and private HTTP endpoints unless destination validation is enforced correctly.

LiteLLM sits in the path between client requests and upstream model providers, so it inherits both proxy trust and cloud exposure. The identity implication is direct: user-level API keys or admin keys can become a route into internal services if request controls are checked at the wrong schema level.

Key questions

Q: What breaks when an LLM gateway's SSRF gate only checks top-level fields?

A: A flat gate fails as soon as the sensitive destination field is nested inside another object or renamed on a sibling endpoint. The proxy still makes the outbound request, so the apparent control only protects one schema shape. Teams should verify validation against the actual request structure for every fetch path, not just the original patched endpoint.

Q: Why do SSRF sinks in AI gateways create cloud credential risk?

A: Because the gateway often runs inside a trusted cloud network and can reach instance metadata, internal APIs, and private services that external clients cannot touch. If the server can be induced to fetch those destinations, the attacker may inherit the runtime's network position and, in some cases, its cloud identity material.

Q: What signs show that SSRF controls are failing in a proxy service?

A: Look for outbound requests that succeed from paths never meant to fetch user input, destinations that can be changed by client data, and error messages that reveal internal hosts or metadata attempts. A control is failing when a listener proves the server is still calling attacker-chosen URLs despite a supposed gate.

Q: How should teams govern outbound fetch features in LLM infrastructure?

A: Treat outbound fetch capability as a privileged function. Restrict which identities can use it, block internal and metadata destinations by policy, and test every endpoint that accepts a URL or base address. If a user can influence where the proxy connects, the access decision belongs in IAM and application controls together.

Technical breakdown

Why outbound request proxies create SSRF exposure

A proxy that accepts URLs or upstream endpoints from a client is structurally exposed to server-side request forgery, because the server itself becomes the network caller. In this case, LiteLLM's role as an LLM gateway means it is expected to fetch external resources, test connections, and reach model services. That makes destination validation the critical boundary. If the code accepts a client-controlled URL and passes it straight into an HTTP client, the server can be induced to reach metadata services, localhost, or internal APIs that the attacker could not contact directly.

Practical implication: Treat every client-controlled outbound fetch as a potential SSRF sink and enforce destination allowlists before any network call.

Nested request bodies defeat flat validation gates

The root issue here is not simply missing validation, but validation that inspects the wrong part of the request structure. A flat check for fields such as api_base or base_url can look effective while still failing when the same values are nested inside objects like litellm_params, or carried under a different field name such as file_url. That mismatch is common in API-heavy systems where one guard is copied across multiple endpoints without matching the actual request schema. A control that assumes a top-level body cannot protect nested parameter handling.

Practical implication: Align input validation with the real request schema and test every endpoint shape, not just the obvious top-level fields.

Cloud metadata access turns SSRF into credential exposure

Once SSRF reaches a cloud metadata service, the issue escalates from simple reachability to credential theft and internal reconnaissance. Metadata endpoints are often used by cloud instances to obtain temporary role credentials, and those credentials may then unlock storage, secrets, or control-plane APIs. In LiteLLM's case, the attack surface is worse because the gateway is already inside the trust boundary of a cloud deployment. Even when an endpoint only returns a timeout or a generic fetch error, the server-side request itself proves that the destination was attempted, which is enough to establish exposure.

Practical implication: Block metadata addresses explicitly and assume any successful server-side request to 169.254.169.254 creates cloud credential risk.

Threat narrative

Attacker objective: The attacker wants to use the LiteLLM host as a trusted network pivot to reach internal services and cloud metadata, then extract credentials or service responses.

1. Entry occurs when an authenticated LiteLLM user submits a request that contains a client-controlled URL or nested api_base value.
2. Credential access follows when the gateway fetches loopback or cloud metadata destinations, creating a path to instance role material or internal service responses.
3. Impact occurs when the proxy is used as a trusted relay into cloud-native or internal HTTP services that the attacker could not otherwise reach.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Nested schema validation is the governance gap here: the control problem is not SSRF in the abstract, but validation that was written for a flat body and deployed into nested request handling. That failure mode is common in proxy-style AI infrastructure, where one endpoint adds a child object and the safeguard no longer sees the sensitive field. For practitioners, this is a control-design problem, not just a code defect.

LLM gateways are becoming implicit identity brokers for cloud access: when a gateway can reach metadata services, user-level authentication on the front door does not prevent cloud credential exposure behind it. The gateway's server-side network reach becomes part of the identity boundary, which means API key scope and outbound fetch policy have to be governed together. The practitioner conclusion is to treat outbound destination control as an access-control issue.

SSRF in AI infrastructure should be framed as cloud trust abuse, not only application security: the danger is amplified because the service lives inside a trusted VPC and is expected to talk to model providers, storage, and supporting services. That trust context makes request laundering possible, especially where egress controls are broad and metadata endpoints are reachable. Teams should assume any proxy that can fetch user-influenced URLs needs explicit cloud-aware guardrails.

Broken validation gates create false assurance debt: once a mitigation is known to exist, teams often stop looking for sibling endpoints that use a different schema. The article shows why that assumption fails, because the same control did not generalize across file_url and nested api_base handling. Practitioners should prioritize control consistency across every fetch path, not just the endpoint originally patched.

Request destination control is now an LLM gateway requirement: if the platform can make outbound HTTP requests on behalf of users, then allowlisting, metadata blocking, and schema-aware validation are part of the product's security baseline. That is especially true where service accounts, provider keys, or instance metadata are reachable from the same runtime. The conclusion for teams is to govern egress as carefully as authentication.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Schema-aware destination validation is now a baseline control for AI infrastructure: proxy services cannot rely on a single guard that inspects one request shape and assume the rest of the code base is covered. The practical pattern is to validate the final outbound target after all nesting, transformation, and endpoint-specific logic has run, then block metadata ranges and loopback addresses before any fetch occurs.

LLM gateways collapse application security and cloud access into one control plane: once a service can fetch on behalf of a user, the question becomes who is allowed to trigger that fetch and what destinations the runtime can reach. Teams should review the gateway as part of identity governance, because a user API key can indirectly become a cloud access path if destination control is weak.

For practitioners

• Validate every outbound URL at the final call site Inspect the actual parameter passed to the HTTP client, including nested objects such as litellm_params and alternate field names like file_url, before any request leaves the process.
• Block cloud metadata and loopback destinations explicitly Deny 169.254.169.254, 127.0.0.0/8, localhost, and other internal ranges at the application layer and again at the network layer to stop request laundering.
• Scope user API keys to non-fetch operations where possible Separate ordinary user actions from endpoints that can trigger server-side requests, and reserve outbound fetch functions for tightly controlled roles.
• Test every proxy endpoint with a live listener Use a controlled listener to prove whether an endpoint really sends traffic, because hangs and timeouts are not evidence of a fetch path on their own.
• Review gateway egress as part of identity governance Map which principals can invoke server-side fetch features and whether those calls can touch internal services, cloud metadata, or provider APIs.

Key takeaways

• The article shows that SSRF in an LLM gateway is not just a web bug, because the same request path can expose cloud metadata and internal services from inside a trusted runtime.
• Escape's testing found three confirmed sinks and a bypassed gate, which is enough to show that request-shape validation failed to contain the attack surface.
• Teams need schema-aware destination controls, explicit metadata blocking, and tight privilege separation for any AI proxy that can make outbound HTTP requests.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Cloud metadata endpoint: A cloud metadata endpoint is a local service that exposes instance details and, in some environments, temporary credentials to workloads running on that instance. It is highly sensitive because SSRF can sometimes reach it from within the application and extract information meant only for trusted code.
• Destination Validation: Destination validation is the control that checks where a server-side request is allowed to go before the request is made. In layered application schemas, it must inspect the final resolved target, not only top-level fields, or attackers can bypass it through nested parameters.
• LLM Gateway: A unified control layer that sits between applications and multiple language model providers. It standardises routing, logging, quotas, and request handling so teams can manage model access through one interface rather than building provider-specific integrations everywhere.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security practitioners who need to connect access governance to emerging AI infrastructure patterns.