LiteLLM SSRF sinks: what they mean for cloud and IAM teams

TL;DR: Three confirmed SSRF sinks in LiteLLM include one reachable by any authenticated user and two admin-only paths that can reach loopback and cloud metadata addresses, while a prior gate intended to block user-supplied destinations is bypassed, according to Escape. The finding matters because LLM gateways routinely sit inside trusted cloud networks, turning weak request validation into a path to instance credentials and internal service access.

NHIMG editorial — based on content published by Escape: LiteLLM SSRF sinks expose cloud metadata and internal services

Questions worth separating out

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.

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.

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.

Practitioner guidance

• 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.
• 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.

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

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

LiteLLM SSRF sinks: what they mean for cloud and IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →