LiteLLM api_base SSRF Leaks Upstream Provider Keys - CVE-2024-6587
CVE-2024-6587 (also tracked as GHSA-g26j-5385-hhw3) is a server-side request forgery in LiteLLM, rated CVSS 7.5. It let a caller make the proxy forward an upstream provider's API key to a domain the caller chose. The flaw existed through version 1.38.10 and was fixed in 1.44.8. This advisory covers what the bug exposed, why a gateway leak is an agentic-endpoint problem, and how Anomity surfaces and governs the agents that route through it.
What happened
LiteLLM Proxy is a gateway that fronts many upstream model providers behind a single OpenAI-compatible API. It holds the provider keys so callers do not have to: a caller sends a request to the proxy, and the proxy attaches the right upstream key and forwards the request to the provider.
In the affected versions, a caller could include an api_base parameter on a POST /chat/completions request. The proxy used that value as the destination without restriction, then sent the upstream request, including the provider's API key in the Authorization header, to whatever domain the caller named. By setting api_base to a server they controlled, a malicious user captured the OpenAI or other provider key from the inbound request.
The immediate impact is unauthorized use of the organization's paid model access: with the leaked key, an attacker can call the provider directly on the organization's account, running up cost and reaching any data the key is scoped to. Because the proxy fronts every upstream provider it holds keys for, a single capture can reach beyond one provider.
Researchers later chained this SSRF with an injection primitive in a Pwn2Own-style demonstration: because the attacker controlled the destination the proxy connected to, crafted HTTP responses were turned into code execution on the proxy host. That escalates the impact from credential theft to full compromise of the gateway. The fix in 1.44.8 restricts outbound base URLs so the proxy will not forward credentials to a caller-controlled destination.
| Detail | Value |
|---|---|
| Identifier | CVE-2024-6587 (GHSA-g26j-5385-hhw3) |
| Type | Server-side request forgery (caller-set api_base) |
| CVSS | 7.5 (High) |
| Affected | LiteLLM through 1.38.10 |
| Fixed in | 1.44.8 (restricts outbound base URLs) |
| Escalation | SSRF chained to injection for RCE on the proxy host (Pwn2Own-style demo) |
Why this is an agentic-endpoint risk
An LLM gateway rarely sits alone. It exists because AI agents, CLIs, and developer tooling need a single place to send model traffic. On a managed endpoint, the LiteLLM process is an AI artifact in its own right, and so are the Claude Code sessions, MCP servers, and command-line agents that point at it. Holding the keys for the whole model fleet makes it the highest-value secret store on the host.
The api_base flaw makes that concentration dangerous in a specific way: the leak is driven by the request itself. An agent or a user passing a crafted parameter through the proxy, whether by mistake, through a poisoned tool definition, or as a deliberate attack, can redirect a provider key to an external destination. Network and EDR controls see the outbound connection, but cannot tell you which agents on which endpoints route through the affected version, or whether any were allowed to set a non-default api_base.
This is the same artifact-layer blind spot we track across the gateway cluster, including the sibling case in LiteLLM pre-auth SQL injection - CVE-2026-42208. The proxy is one node in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping a leak like this one.
How Anomity surfaces and governs it
Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2024-6587 that means the LiteLLM process and its version are catalogued alongside the agents and CLIs that route through it, so you can answer "which endpoints run an affected proxy build, and what talks to it" from the fleet inventory instead of guessing.
On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that routes through a known-vulnerable proxy version, or that carries a non-default api_base pointing at an unapproved destination, can be denied or logged in line rather than discovered after the provider bill arrives. Anomity collects metadata only and redacts secrets on the endpoint, so it never has to read the very keys this bug targets.
Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail lets responders scope the event: which agents called through the proxy, when, and whether any call attempted to redirect outbound traffic. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.
Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them. It adds the agentic-endpoint layer those tools cannot see. See how it works and how Anomity compares for where it fits.
What to check across your fleet
- Identify every endpoint and service running LiteLLM and record the exact version; treat anything at or below 1.38.10 as affected.
- Upgrade to 1.44.8 or later, which restricts outbound base URLs so the proxy will not forward credentials to a caller-controlled destination.
- Rotate every upstream model-provider key the proxy held, since a successful api_base capture exposes the keys for the connected providers.
- Review provider billing and usage logs for unexpected activity that could indicate a leaked key was used directly against the provider account.
- Confirm callers cannot override api_base or other destination parameters, and block non-default outbound base URLs at the proxy and the network edge.
- Restrict network reachability so the proxy is not exposed to untrusted callers, and require authentication in front of the model routes.
- Enumerate which AI agents, CLIs, and MCP servers route through the affected proxy, using a fleet-wide AI artifact inventory, and confirm hook-based allow/deny/log enforcement is active on agents that route model traffic.
CVE-2024-6587 shows how one forwarded request can turn a gateway into a credential leak and, when chained, into code execution on the host. That is why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing LLM gateways and proxies. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.
Frequently asked questions
Does upgrading LiteLLM to 1.44.8 fully resolve CVE-2024-6587?
Upgrading to LiteLLM 1.44.8 or later closes the bug by restricting which outbound base URLs the proxy will send a request to, so a caller can no longer redirect traffic to an arbitrary domain. The upgrade stops the leak, but it does not undo a leak that already happened. Any deployment that ran an affected build (through 1.38.10) while reachable by untrusted callers should be treated as a potential key disclosure. Rotate every upstream model-provider key the proxy held, review provider billing and usage for unexpected activity, and confirm no caller successfully set api_base to an external domain before assuming the incident is closed.
How exactly did the api_base parameter leak the provider key?
LiteLLM Proxy fronts upstream model providers and holds their API keys so callers do not have to. In the affected versions, a caller could include an api_base parameter on a POST /chat/completions request. The proxy took that value at face value and sent the upstream request, with the provider's key in the Authorization header, to whatever domain the caller named. By pointing api_base at a server they controlled, an attacker captured the OpenAI or other provider key in the inbound request. The fix restricts outbound base URLs so the proxy will not forward credentials to a caller-controlled destination.
Was CVE-2024-6587 chained into something worse than a key leak?
Yes. Researchers later combined this SSRF with an injection primitive in a Pwn2Own-style demonstration. By controlling the destination the proxy connected to, they could shape the HTTP response the proxy received, and crafted responses were turned into code execution on the proxy host. That escalation moves the impact from credential theft to full compromise of the gateway, which sits in front of the whole model fleet. It is the reference case for a simple rule: a gateway must never forward credentials, or follow connections, to a destination the caller chose.
How does Anomity reduce exposure when a gateway like LiteLLM is compromised?
Anomity treats the LLM gateway as an AI artifact on the endpoint, so it inventories the LiteLLM process, its version, and the local agents and CLIs that route through it. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, so a call that routes through a known-vulnerable proxy version or sets a non-default api_base can be denied or logged in line. Every decision lands in a queryable 90-day audit trail, giving responders the timeline they need to scope a key-leak event across the fleet.