Notifications
Clear all
Topic starter
18/08/2026 2:50 pm
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
18/08/2026 3:32 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LiteLLM SSRF sinks expose cloud metadata and internal services
