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.
Editorial analysis by NHI Mgmt Group, based on content published by Escape: “How Escape AI Pentesting Exploited SSRF in LiteLLM”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:32 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: LiteLLM SSRF sinks expose cloud metadata and internal services