LiteLLM RCE shows how AI gateways expand the attack surface

At a glance

What this is: This is a security research post about a LiteLLM vulnerability chain that enables unauthenticated RCE on AI proxy deployments and exposes credentials plus downstream systems.

Why it matters: It matters because AI gateways sit on sensitive identity and secret paths, so gateway authentication, runtime execution controls, and workload segmentation all become part of the identity security model.

Context

AI gateways are now part of the identity boundary for AI infrastructure because they broker access to model providers, secrets, and downstream services. When that boundary accepts untrusted input into runtime execution paths, the problem is no longer only network exposure or application hardening, but governance of what the gateway is allowed to do on the host.

In this case, the issue is not simply that LiteLLM was reachable. The deeper failure is that a proxy that carries model API keys and other secrets also exposed command execution through MCP test endpoints, which means compromise of the gateway becomes compromise of the broader AI stack. That is a familiar pattern in AI infrastructure, and in this article it is the central risk.

Key questions

Q: What breaks when an AI gateway exposes command execution through an internal test endpoint?

A: The gateway stops being a broker and becomes an execution surface. If a test endpoint accepts command, argument, or environment input, any reachability flaw can turn that input into host-level code execution. The result is not just application abuse. It is secret exposure, credential theft, and a pivot point into whatever systems the gateway can reach.

Q: Why do AI proxy compromises create such a large blast radius?

A: Because the proxy often concentrates model provider credentials, environment secrets, and trust links to downstream services. Once it is compromised, the attacker is not confined to one request path. They can steal secrets, impersonate the gateway, and move into connected AI infrastructure or backend systems that trust the proxy.

Q: How should teams detect exploitation of AI gateway runtime paths?

A: Look for unexpected subprocess creation, unusual command arguments, and request-to-process correlations from sensitive endpoints. Detection should connect the inbound request with the resulting host behaviour, because network visibility alone will miss the moment a configuration field becomes an executed command.

Q: Should security teams treat authentication as enough protection for AI gateways?

A: No. Authentication is necessary, but it does not neutralise unsafe host execution, exposed management endpoints, or dependency flaws that let attackers bypass access checks. AI gateways need both identity controls and runtime containment, because a validated caller can still trigger dangerous behaviour if the host surface is exposed.

Technical breakdown

How the LiteLLM attack chain turns gateway input into host execution

LiteLLM exposed MCP server test endpoints that accepted a full server configuration, including command, arguments, and environment variables. That configuration was passed into a subprocess call, so user-controlled input could become host-level execution if the endpoint was reachable. The CVE-2026-42271 issue was not a logic bug in model handling, but a classic injection path where configuration becomes code execution. Once that happens inside an AI gateway, the proxy is no longer just brokering requests. It becomes an execution surface with access to local secrets and any credentials loaded into its runtime environment.

Practical implication: Treat any AI gateway endpoint that can spawn processes as an execution boundary, not a configuration helper.

Why the Host header bypass changed the authentication model

The article states that the original path required a valid proxy API key, but CVE-2026-48710 allowed attackers to skip that requirement by abusing Host header validation in Starlette-based applications. That matters because the security model shifted from authenticated misuse to unauthenticated reachability. In identity terms, the control failure is not only weak authentication, but an assumption that the proxy can trust origin metadata before it evaluates whether a caller should reach sensitive runtime functions. When that assumption fails, the gateway can be attacked directly from the network edge even if a key was supposed to protect the endpoint.

Practical implication: Separate reachability controls from authentication controls and block sensitive endpoints before application-level identity checks are even evaluated.

Why AI proxies concentrate secrets and lateral movement risk

AI proxies such as LiteLLM often sit between applications and model providers like OpenAI, Anthropic, and Azure. That placement makes them a high-value concentration point for model API keys, environment secrets, and trust relationships to downstream systems. The compromise is therefore not limited to one workload. It creates a bridge from the proxy into provider credentials and connected services, which is why AI infrastructure should be treated as a secret-bearing control plane rather than a simple middleware layer. When a gateway is both an identity broker and an execution host, blast radius grows with every integration it holds.

Practical implication: Inventory AI proxy secrets and downstream trust links as if the proxy were a privileged identity system.

Threat narrative

Attacker objective: The attacker aims to execute commands on the AI proxy host and use that foothold to steal credentials and pivot into connected systems.

1. Entry occurred through a publicly reachable LiteLLM deployment where a crafted request could reach exposed MCP test endpoints.
2. Credential checks were bypassed through a Starlette Host header flaw, allowing unauthenticated access to a function that accepted command input.
3. Escalation happened when unsanitized input was passed to a subprocess call on the AI gateway host, producing arbitrary command execution.
4. Impact included access to model provider credentials, proxy secrets, and lateral movement into connected AI infrastructure and backend systems.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI gateways are now privileged identity infrastructure, not just integration middleware. When a proxy holds model API keys, environment secrets, and trust relationships to downstream services, its compromise becomes an identity event as much as an application one. That changes how teams should classify exposure: the blast radius is defined by the secrets and system access concentrated in the gateway, not by the gateway's own business function. Practitioners should govern these proxies as privileged control points.

Authentication at the edge does not compensate for unsafe runtime execution inside the gateway. The article shows a control gap where a host-reachable subprocess path remained exposed behind what looked like a valid access gate. That is a classic governance failure for AI infrastructure because identity checks can be satisfied while the host still executes attacker-controlled commands. The practitioner conclusion is that runtime authority must be treated as a separate control plane from request authentication.

Runtime command execution inside AI infrastructure creates an identity blast radius that conventional gateway thinking misses. LiteLLM sits between applications and providers, so a single compromise can expose multiple credentials and connected systems at once. That makes secret scope, execution scope, and trust scope inseparable in AI proxy design. Security teams should assume that one reachable subprocess path can become a multi-system identity compromise.

Conditional trust assumptions break down when an AI proxy can act on behalf of many principals. The proxy is asked to authenticate callers, but it also carries provider credentials and can spawn host processes. That combination means a single trust boundary is doing too many jobs. The practical result is that governance models built around a single authenticated session are too narrow for AI gateways that broker both secrets and execution.

LiteLLM-style gateway exposure validates the need to govern AI infrastructure as a workload-identity problem. The security question is not only who can call the gateway, but what identities, secrets, and host privileges the gateway itself can use once called. That is where the attack surface expands fastest, and it is where identity teams need to join application security and platform security conversations.

From our research library:

• 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.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Identity teams need to treat AI gateways as privileged workloads. The useful question is not whether the gateway authenticates callers, but whether the gateway itself can execute actions with privileged access to secrets and downstream services. That shifts governance toward workload identity, secret scope, and host execution boundaries, because those are the controls that define the real blast radius.

Runtime authority is the missing control layer in most AI proxy deployments. Access reviews and perimeter checks do not help if a validated or bypassed request can still spawn a subprocess on the host. Security teams should align AI infrastructure governance with workload identity controls and runtime containment, including the patterns covered in the AI Infrastructure Workload Identity Guide.

For practitioners

• Restrict MCP test endpoints Block public access to /mcp-rest/test/connection and /mcp-rest/test/tools/list, because those paths accept command-bearing configuration and should never be reachable from untrusted networks.
• Patch the LiteLLM and Starlette dependency chain Move LiteLLM to version 1.83.7 or later and verify the Starlette dependency no longer exposes the Host header validation bypass described in the article.
• Inventory gateway-held secrets and provider trust paths Map every model API key, environment secret, and downstream integration that the AI proxy can reach so you understand the blast radius if the gateway is compromised.
• Monitor runtime subprocess behaviour Watch for unexpected child processes spawned by the proxy and correlate them with inbound requests, especially any request that touches the MCP endpoints.
• Constrain AI proxy access to trusted network segments Place the proxy behind network controls that limit who can reach sensitive runtime functions, and do not rely on application authentication alone for containment.

Key takeaways

• AI gateways can become identity-critical choke points when they store provider credentials and can also execute host commands.
• The LiteLLM chain described by Oligo Security shows how an authentication bypass plus unsafe subprocess handling can expose an entire AI stack.
• Teams need to govern AI proxies as privileged workloads, with runtime containment and secret scoping as first-class controls.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• Runtime Execution Surface: A runtime execution surface is any application path that can cause code, commands, or subprocesses to run on the host. For AI infrastructure, this matters because a gateway may look like an integration layer while actually holding the power to execute host-level actions.
• Secret Concentration: The practice of storing many reusable credentials, tokens, or certificates in one operational platform so it can do its job across systems. This reduces friction, but it also creates a high-blast-radius target because one compromise can expose access to many dependent services.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.