LiteLLM RCE shows how AI gateways expand the attack surface

At a glance

What this is: This is an analysis of a LiteLLM vulnerability chain that enables unauthenticated RCE against AI proxy gateways and exposes secrets, credentials, and downstream systems.

Why it matters: It matters because AI gateway compromise can turn one exposed proxy into a control point for NHI, workload, and agentic access across the broader AI stack.

By the numbers:

• LiteLLM 1.74.2 through 1.83.6 are affected when the dependency tree includes Starlette version 1.0.0 or earlier.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Oligo Security's analysis of the LiteLLM RCE chain and AI proxy exposure

Context

LiteLLM acts as a proxy layer between applications and model providers, so compromise of that layer is not a narrow application bug. In practice, it becomes an identity and access control problem because the proxy often holds model API keys, secrets, and routing authority for downstream AI services.

The vulnerability chain described by the vendor shows why AI gateway security cannot stop at authentication. When command execution is reachable inside the proxy process, the issue extends beyond application logic into NHI exposure, secrets handling, and the privilege boundary that separates the AI stack from the rest of the environment.

Key questions

Q: What breaks when an AI proxy can execute host commands from a request?

A: The security boundary breaks at the process level. A request can become operating-system execution, which means the proxy is no longer just forwarding model traffic. It can expose secrets, tokens, and upstream credentials that were assumed to be protected by application authentication. That is why AI gateways must be treated as privileged workloads, not ordinary web services.

Q: Why do AI gateway vulnerabilities increase non-human identity risk?

A: Because the gateway often holds model API keys, workload secrets, and routing authority for downstream services. If an attacker controls the gateway process, they can inherit the non-human identities that the proxy uses to talk to model providers and connected systems. The identity impact is broader than the original CVE because one proxy may concentrate many privileges.

Q: How can security teams reduce blast radius in LLM proxy deployments?

A: Scope proxy privileges as tightly as possible, remove secrets that do not need to live in the process environment, and isolate any command-spawning functionality from internet-facing paths. The goal is to stop a single runtime flaw from becoming full AI stack compromise. Segmentation, secret minimisation, and execution control matter more than trust in the proxy layer.

Q: Who is responsible when an AI gateway exposes model credentials and downstream systems?

A: Responsibility usually sits with the platform, application, and identity teams together because the failure spans infrastructure, secrets management, and access governance. If the proxy is treated as a simple app, ownership gaps are likely. AI gateways need explicit control ownership, documented trust boundaries, and reviewable operational accountability across the stack.

Technical breakdown

Unauthenticated RCE through exposed MCP test endpoints

The attack chain begins with LiteLLM's MCP server test endpoints, which accept server configuration fields such as command, arguments, and environment variables. If those fields are passed into a subprocess call without sanitisation or sandboxing, attacker-supplied input becomes host command execution. A Starlette Host header bypass then removes the original API-key gate, turning what looked like an authenticated test interface into a remotely reachable execution path. The result is not just a bad request handling flaw. It is a direct bridge from HTTP input to operating system action.

Practical implication: block or remove externally reachable test endpoints and treat any command-spawning API surface as an execution path, not a debugging feature.

Why AI gateways expose more than model traffic

A proxy like LiteLLM is structurally different from a normal web application because it sits in the trust path for model requests, credentials, and routing decisions. That makes the process boundary especially sensitive: if the proxy is compromised, the attacker inherits whatever secrets, tokens, and environment variables the service can reach. In AI infrastructure, the gateway often becomes a concentration point for non-human identity material, not merely a traffic router. That is why runtime command execution on the proxy is so dangerous. It can convert a single application flaw into broad AI-stack compromise.

Practical implication: inventory every secret, token, and upstream credential reachable from the proxy process and reduce that blast radius before exposure is discovered.

Runtime blocking versus patch-cycle exposure

The vendor's detection model matters because exploitation can occur before a patch is deployed everywhere. Runtime enforcement intercepts the subprocess call at execution time, which is different from perimeter filtering or signature-based detection. That distinction is important in AI environments where proxy services are often shared, exposed, or embedded in fast-moving release pipelines. If the exploit lands between patch cycles, only a control that understands the process tree and command invocation can stop it reliably.

Practical implication: pair patching with runtime controls that can stop unexpected child processes on AI infrastructure hosts.

Threat narrative

Attacker objective: The attacker wants privileged access to the AI gateway host so they can steal secrets, pivot into connected systems, and control downstream AI workflows.

1. Entry occurs when an attacker reaches exposed LiteLLM test endpoints and abuses the Starlette Host header bypass to skip the intended API-key check.
2. Credential access follows because the compromised proxy can expose model API keys, environment secrets, and downstream authentication material stored or reachable on the host.
3. Escalation happens when malicious command arguments are executed as a subprocess, giving the attacker code execution on the AI infrastructure host and a foothold for lateral movement.
4. Impact is full compromise of the proxy-backed AI supply chain, including access to connected applications and backend systems that trust the gateway.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI gateway RCE is an identity problem before it is an application bug. LiteLLM sits in the trust path for model traffic, so a successful compromise is really a failure of non-human identity boundary control. Once command execution exists inside the proxy, the attacker is no longer just exploiting code. They are inheriting the credential and routing authority that the gateway holds for the AI stack. Practitioners should treat proxy-layer execution as a privileged identity event, not a routine vulnerability.

Runtime API authentication is a brittle control when the same process can spawn commands. The article shows the original security assumption was that an API key would protect the risky endpoints. That assumption fails when the endpoint itself can execute host commands because the attacker does not need durable access. The implication is that identity controls built around request approval do not contain process-level abuse in AI infrastructure.

Command execution inside an LLM proxy creates identity blast radius. This is the specific failure mode exposed here: a single reachable subprocess call turns one proxy into a bridge to secrets, tokens, and downstream systems. That is a named governance concept worth tracking because it explains why AI gateways need tighter process isolation than conventional application services. Practitioners should map every gateway feature that can touch the operating system and classify it as blast-radius increasing.

Secrets stored near AI routing logic become compound exposure, not isolated leakage. The proxy is not merely passing model requests through. It often carries model provider credentials and environment-based secrets that are immediately useful once the host is compromised. That means secrets management, workload identity, and runtime hardening have to be designed together. The practical conclusion is that gateways should not be trusted as benign middle tiers when they are also execution environments.

OWASP NHI and Zero Trust principles both apply here because the proxy is a workload identity boundary. A remote request that can reach command execution has already crossed the assumption that only authorised, bounded workload behaviour will occur. The governance response is not to treat the gateway as a generic web app, but to align it with NHI controls for secret containment, process restriction, and least-privilege exposure. Practitioners should govern AI proxies as high-risk identity infrastructure.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• That policy gap points directly to a broader governance shift, which is why practitioners should also review the OWASP NHI Top 10 alongside proxy hardening work.

What this signals

Command-spawning AI proxies create an identity blast radius that conventional app controls do not model well. When a gateway can execute host processes and already holds model credentials, the security problem is no longer just web exposure. Practitioners should watch for any AI infrastructure component that merges routing, secrets, and runtime execution in one trust zone.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the gateway is becoming a privilege concentration point rather than a neutral broker. That makes least privilege, process isolation, and secret minimisation the controls that define whether the AI stack stays governable.

Identity blast radius: a proxy or platform layer that concentrates credentials, routing authority, and execution capability into a single trust boundary. Once that boundary is exposed, the programme needs to rethink where identity ends and workload control begins, especially for AI gateways that can touch the operating system.

For practitioners

• Patch the proxy and its dependency chain immediately Upgrade LiteLLM to the fixed version or later and verify whether Starlette remains within the vulnerable range in the deployment tree.
• Disable externally reachable test endpoints Block access to /mcp-rest/test/connection and /mcp-rest/test/tools/list unless they are strictly internal and protected by network segmentation.
• Reduce secrets reachable from the proxy process Move model provider credentials and other sensitive environment values out of the proxy runtime wherever possible, and scope what the service account can read.
• Monitor for unexpected child processes Alert on new subprocess execution from the proxy host, especially when it is triggered by HTTP requests with unusual Host headers or command arguments.
• Treat AI gateways as privileged workloads Apply tighter network placement, host hardening, and process-level enforcement to any AI proxy that can touch model credentials or downstream APIs.

Key takeaways

• A LiteLLM command execution flaw turns the AI proxy into a privileged identity boundary, not just an application component.
• The attack chain is dangerous because it combines unauthenticated access, credential exposure, and host-level subprocess execution.
• The limiting control is not authentication alone but runtime enforcement, secret minimisation, and strict containment of gateway privileges.

Key terms

• AI Gateway: An AI gateway is a proxy layer that routes requests between applications and model providers while often carrying credentials, policy logic, and observability. In security terms, it is a workload boundary with identity significance because compromise can expose secrets, downstream systems, and provider access at once.
• Subprocess Execution: Subprocess execution occurs when an application spawns operating-system commands as part of its runtime behaviour. In a privileged service, this becomes a high-risk capability because untrusted input can cross from application data into host-level action, turning a request handling flaw into code execution.
• Identity Blast Radius: Identity blast radius is the amount of additional access, trust, and downstream reach an attacker gains after compromising one workload or identity. In AI proxy environments, it expands quickly because the proxy may hold provider keys, routing authority, and environment-based secrets in a single process.
• Runtime Enforcement: Runtime enforcement is a control that blocks or constrains dangerous behaviour while software is running, rather than only detecting it after the fact. For AI infrastructure, it can stop unexpected command execution, isolate process activity, and reduce the time between exploit attempt and containment.

What's in the full article

Oligo Security's full security research covers the operational detail this post intentionally leaves for the source:

• Exact vulnerable endpoint behaviour and request flow details for reproducing the issue in a controlled environment
• Runtime detection and blocking examples showing how the exploit is intercepted at the call stack level
• Patch guidance and dependency versioning considerations for affected LiteLLM deployments
• Illustrative alerting context that helps incident responders distinguish malicious subprocess activity from normal gateway behaviour

👉 The full Oligo Security post covers the exploit chain, runtime blocking approach, and remediation steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.