LiteLLM SSRF sinks expose cloud metadata and internal services

At a glance

What this is: Escape found three confirmed SSRF sinks in LiteLLM, including a bypass of a security gate meant to stop user-controlled outbound requests.

Why it matters: This matters because LLM gateways operate inside trusted cloud environments, so SSRF can turn ordinary API access into cloud metadata exposure, internal service reachability, and privilege escalation.

By the numbers:

• The server attempted to reach 169.254.169.254, the cloud instance metadata address, during testing.

👉 Read Escape's analysis of LiteLLM's SSRF sinks and gateway bypass

Context

LLM gateways are not just application proxies. They are infrastructure services that make outbound HTTP requests on behalf of users, which means weak destination validation can become a direct path to SSRF, metadata exposure, and internal network probing. In cloud environments, that creates an identity and access problem as much as an application security problem, because the service often runs with privileges that reach beyond the caller's own access.

The LiteLLM findings show how quickly a single validation assumption can fail when request shapes are nested, endpoints differ, and controls are written for one schema but deployed across several. The issue is not unique to one product category. Any gateway, RAG pipeline, or model proxy that accepts user-influenced URLs needs to be treated as a potential trust boundary for secrets, workload identity, and cloud credentials.

Key questions

Q: What breaks when an LLM gateway only validates outbound URLs at the request edge?

A: Flat validation breaks when the application accepts equivalent URL fields inside nested objects or alternate parameter names. The request may pass the gate while the sink still performs the fetch. That creates an SSRF path even when the code appears to reject dangerous destinations, so validation must be enforced where the network call happens.

Q: Why do LLM gateways increase the risk of cloud credential exposure?

A: They sit inside trusted networks and are built to make outbound requests on behalf of users. If an attacker can influence the destination, the gateway can be turned toward metadata services, internal APIs, or private hosts. The service account and host environment then become part of the attacker path, not just the user session.

Q: How can security teams tell whether SSRF controls are actually working?

A: Look for evidence that untrusted input cannot change upstream destinations, that egress policies block unexpected targets, and that internal services still require authentication even when reached from inside the network. Good controls reduce both successful connections to private resources and the amount of useful data an application can return if probed.

Q: Who is accountable when a proxy service exposes internal metadata through SSRF?

A: Accountability usually spans the application owner, the platform team responsible for the runtime, and the security team that approved the trust boundary. If the service can reach cloud metadata or internal services, the ownership model should include egress controls, credential scope, and testing for nested input paths before release.

Technical breakdown

Why LLM gateways become SSRF targets

An LLM gateway brokers requests between users and upstream model providers, so it naturally handles outbound traffic and remote destinations. That design makes SSRF possible whenever a client can influence the URL, host, or request path that the gateway fetches. The security question is not whether outbound requests are needed, but whether destination control is enforced at every input boundary, including nested fields, alternate parameter names, and callback-style endpoints.

Practical implication: validate every user-influenced destination against an allowlist before any fetch occurs, regardless of request shape.

Why nested request bodies break flat validation gates

Flat validation checks look for banned parameters at the top level of a JSON body, but modern APIs often place those same values inside child objects such as litellm_params. When a control only inspects the outer object, the same dangerous field can still reach the fetch path unchanged. This is a common failure mode in security gates that were written after one bug report and then assumed to cover the whole product.

Practical implication: enforce validation at the sink, not just at the request edge, and test nested schema variants explicitly.

What full-read SSRF changes compared with blind SSRF

Blind SSRF only proves reachability, but full-read SSRF returns the upstream response body to the attacker. That changes the impact from internal probing to content extraction, service fingerprinting, and possible credential theft if the target is metadata or another authenticated internal endpoint. In cloud-hosted infrastructure, that can expose instance roles, internal headers, or service responses that should never be externally visible.

Practical implication: treat any SSRF sink that reflects response content as a credential and data exposure issue, not just a networking flaw.

Threat narrative

Attacker objective: The attacker aims to use the gateway as a proxy into internal networks and cloud metadata services, then extract credentials or sensitive service responses.

1. Entry occurs when an authenticated user supplies a URL to an endpoint that performs outbound fetching on their behalf.
2. Escalation happens when nested request parameters bypass the validation gate and the service reaches loopback or cloud metadata destinations without destination checks.
3. Impact is credential theft, internal service access, or response-body extraction from trusted infrastructure through the proxy.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Request validation is not a security boundary when the sink is the real trust decision. LiteLLM shows the classic failure mode where a gate checks one request shape, but the fetch path accepts another. That means the control is evaluated too early and too shallowly to matter. For practitioners, the lesson is that destination governance must be enforced at the exact point where the network call is made.

LLM gateways turn outbound HTTP into an identity and privilege problem. Once a proxy can reach cloud metadata or internal services, the caller's identity is no longer the only identity that matters. The gateway's workload identity, egress posture, and internal trust relationships become part of the attack surface. That should shift review from application features to the privileges carried by the service account and host environment.

Nested schemas create a governance blind spot that security testing must intentionally target. A flat allowlist or denylist can look complete in review and still fail in production if the application accepts the same field inside child objects. This is a named concept worth tracking as schema-shape bypass: controls that match one payload layout but miss equivalent dangerous inputs embedded elsewhere. Practitioners should test by sink, not by parameter name.

Full-read SSRF is materially worse than simple reachability probing. When the application returns upstream response bodies, the attacker can harvest content, error messages, and metadata responses instead of just confirming that a host exists. That changes severity and response planning, especially where cloud metadata, internal HTTP APIs, or service dashboards are reachable from the proxy. Teams should treat response reflection as a data exposure control issue, not a routing bug.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to The 2026 Infrastructure Identity Survey.
• 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Forward view: Explore Guide to the Secret Sprawl Challenge for the access-control and lifecycle patterns that help contain proxy-driven exposure.

What this signals

Schema-shape bypass should now be treated as a recurring governance issue in AI infrastructure, not a one-off coding mistake. When controls only recognise one request layout, attackers will simply move the dangerous field into a nested structure and keep the same outcome. The practical response is to align validation with sink behaviour, then test that behaviour against the paths your API documentation does not make obvious.

The identity dimension is equally clear: a proxy that can reach metadata services inherits a powerful workload identity, even if the human caller looks low-risk. That means cloud role scope, metadata access, and egress policy need to be reviewed together. Teams building RAG pipelines or model gateways should use the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework as supporting references, but only after proving the service cannot be used as a credential transport layer.

For programmes running AI infrastructure in cloud environments, the signal is not that outbound requests are bad. The signal is that every outbound-capable service needs the same discipline applied to privileged accounts: least privilege, narrow egress, and explicit ownership of the trust boundary. Where that is absent, SSRF is not an edge case but a predictable consequence.

For practitioners

• Test fetch sinks by payload shape, not just by endpoint list Build SSRF test cases for top-level fields, nested objects, and alternate names such as file_url, api_base, and base_url. Validate that the request never reaches loopback, link-local, or private address ranges, even when the field is buried inside child objects.
• Block link-local and private destinations at the sink Apply destination validation immediately before the outbound request, and reject loopback, RFC 1918, link-local, and metadata service addresses before any DNS resolution or connection attempt.
• Remove cloud credentials from proxy hosts where possible Assume an SSRF bypass will eventually reach the host. Reduce blast radius by using scoped instance profiles, disabling unnecessary metadata access, and separating gateway workloads from environments that hold high-value credentials.
• Treat admin-only fetch features as high-risk controls Restrict outbound test endpoints to tightly scoped administrative roles, log every destination attempted, and review any feature that reflects upstream responses as a potential full-read SSRF path.

Key takeaways

• LiteLLM’s issue is not simply SSRF, but SSRF in a service that already sits inside trusted cloud networks and can touch sensitive destinations.
• The bypassed validation gate shows how flat request checks fail when dangerous parameters move into nested schemas or alternate field names.
• Practitioners should verify sink-level destination controls, tighten workload identity scope, and test for full-read SSRF before deployment.

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.
• Full-Read SSRF: Full-read SSRF is a form of SSRF where the attacker can see the upstream response body, not just prove that a request was made. That makes it more dangerous than blind SSRF because it can leak sensitive content, error messages, and internal service responses.
• Instance Metadata Service: Instance Metadata Service, or IMDS, is a local endpoint that exposes instance information and, in Azure, can mint tokens for attached managed identities. It is designed for trusted workloads on the host, so compromise of the machine can become compromise of the identity if access is not tightly controlled.
• Schema-Shape Bypass: Schema-shape bypass is a control failure where validation checks one request layout but misses the same dangerous value when it appears in nested objects or alternate field names. It is a common cause of security gates failing in complex APIs.

What's in the full report

Escape's full analysis covers the operational detail this post intentionally leaves for the source:

• Reproducible request payloads for each confirmed SSRF sink, including the admin-only paths and their exact response behaviour
• Code-level walk-throughs showing where the validation gate checks the wrong request shape and how the bypass works
• Listener output and error traces that demonstrate reachability to loopback and cloud metadata destinations
• Patch verification guidance for teams that want to test whether their own gateway patterns are vulnerable

👉 The full Escape write-up includes proof payloads, listener evidence, and the code paths behind each sink.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the runtime risks created by cloud gateways and AI infrastructure.