AI Gateway Compromise: Chained Starlette and LiteLLM Flaws Expose Foundation Model Keys

Threat actors are actively weaponizing a critical vulnerability chain spanning the Starlette ASGI framework and the LiteLLM proxy gateway to execute unauthenticated remote code execution and harvest upstream enterprise artificial intelligence credentials. The campaign targets centralized AI control planes, prompting the Cybersecurity and Infrastructure Security Agency to add the flaws to its Known Exploited Vulnerabilities catalog with an urgent federal remediation deadline of September 16, 2026.

Rather than functioning as passive HTTP forwarders, modern AI gateways operate as high-privilege clearinghouses. Deployments running LiteLLM aggregate master credentials for external model providers—including OpenAI, Anthropic, and Azure OpenAI—alongside database strings and internal routing topologies. While proprietary foundation model weights and training datasets remain isolated on provider infrastructure, compromising the gateway surrenders the cryptographic keys, virtual tenant tokens, and administrative access that govern enterprise AI workflows.

[[image:poster]]

Anatomy of the Exploit Chain: BadHost to Subprocess Execution

The intrusion chain couples an architectural mismatch in Python Asynchronous Server Gateway Interface (ASGI) request handling with an unvalidated command sink in LiteLLM's Model Context Protocol (MCP) suite.

In ASGI web stacks powered by Uvicorn or Hypercorn, incoming requests populate the underlying scope dictionary: the request line populates scope["path"], while client headers reside in scope["headers"]. In Starlette versions 1.0.0 and earlier, the framework synthesized its internal Request.url property by concatenating the raw, unvalidated HTTP Host header directly onto the request path.

# Vulnerable Starlette URL synthesis (starlette/datastructures.py <= 1.0.0)
host_header = dict(scope["headers"]).get(b"host", b"localhost").decode()
url = f"{scope['scheme']}://{host_header}{scope['path']}"

When an attacker submits an HTTP request embedding path and query delimiters within the Host header, URL parsing breaks down:

POST /mcp-rest/test/connection HTTP/1.1
Host: gateway.internal/health?x=
Content-Type: application/json

{
 "command": "bash",
 "args": ["-c", "id > /tmp/pwned"],
 "env": {}
}

Starlette evaluates the combined string http://gateway.internal/health?x=/mcp-rest/test/connection. Standard URI parsing extracts /health as request.url.path, while the true target path becomes an arbitrary query argument.

LiteLLM's authentication middleware evaluates request.url.path against an allowlist of public diagnostic routes, identifying /health and immediately bypassing bearer token verification. However, Starlette and FastAPI dispatch handlers using scope["path"], which remains /mcp-rest/test/connection.

The unauthenticated request reaches the MCP testing endpoint, which was designed to validate external tool integrations over standard input/output (stdio) channels. The endpoint unpacks user-supplied parameters directly into Python's asynchronous process execution primitives without command whitelisting or argument sanitization:

# Simplified representation of the execution sink in LiteLLM
async def test_mcp_connection(data: MCPTestInput):
 server_params = StdioServerParameters(command=data.command, args=data.args, env={**os.environ, **data.env})
 process = await asyncio.create_subprocess_exec(
 server_params.command, *server_params.args, env=server_params.env,
 stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE
 )

This structural failure grants adversaries immediate command execution under the privileges of the running gateway container.

Control-Plane Infiltration and Credential Harvesting

Once inside the container environment, threat actors bypass application boundaries to extract infrastructure secrets. Because LiteLLM typically executes as the entrypoint process (PID 1) in containerized deployments, inspecting /proc/1/environ immediately yields plaintext administrative variables, including LITELLM_MASTER_KEY and the relational database connection string (DATABASE_URL).

Adversaries leverage these database coordinates to dump two central PostgreSQL tables:

1. LiteLLM_ProxyModelTable: Houses the litellm_params JSON object, exposing raw upstream API keys for OpenAI, Anthropic, Azure OpenAI, and AWS Bedrock, along with private enterprise endpoints.
2. LiteLLM_VerificationToken: Contains proxy-issued virtual API keys, spend limits, allowed model scopes, and internal client team identities.

By obtaining these assets, attackers gain complete operational control over upstream model consumption and downstream API routing, enabling data interception, quota exhaustion, and administrative backdoor insertion without accessing physical model weights.

Threat Actor Profile and Host Persistence

Observed intrusions demonstrate a disciplined post-exploitation lifecycle focused on covert persistence and hardware monetization. Threat actors deploy multi-stage droppers into memory-backed locations such as /dev/shm and /tmp, masquerading binary processes under system names such as python3 [systemd-journald] or kworker_ds.

To maximize Monero mining performance on high-performance compute instances, adversaries tamper with low-level CPU registers via the Linux Model-Specific Register module (modprobe msr), executing wrmsr -a 0xc0011020 0x0 to disable hardware prefetchers for the RandomX algorithm. The actors subsequently terminate rival cryptominers, lock cron entries using the immutable filesystem flag (chattr +i), and append unauthorized Ed25519 public keys to ~/.ssh/authorized_keys.

Zero-Downtime Key Rotation Strategy

Revoking all compromised credentials simultaneously causes severe operational outages across production AI applications. Engineering teams must deploy an orchestrated, multi-phase key rotation protocol.

1. Dual-Key Provisioning: Generate secondary API keys directly within upstream provider portals (OpenAI, Anthropic, Azure) without deleting the active credentials.
2. Live Gateway Updates: Hot-swap upstream secrets by updating the litellm_params JSON payload in LiteLLM_ProxyModelTable or invoking LiteLLM's administrative /model/update endpoint, avoiding service interruption.
3. Infrastructure Secret Cycling: Rotate backend database user passwords, update orchestrator secret manifests (DATABASE_URL, LITELLM_MASTER_KEY), and execute a rolling container rollout (kubectl rollout restart).
4. Provider Key Decommissioning: Track upstream provider usage logs. Once external request volume across legacy keys flatlines for fifteen consecutive minutes, permanently revoke the compromised credentials.
5. Virtual Token Re-Keying: Issue replacement virtual tokens across downstream application teams, maintain a 48-hour deprecation window, and purge retired tokens via /key/delete.

Architectural Hardening and Defenses

Mitigating gateway compromise requires defense-in-depth spanning dependency management, ingress normalization, and container sandboxing.

Package Upgrades and Route Deactivation

Platform teams must upgrade Starlette to version 1.0.1 or higher, which enforces strict RFC 3986 validation over Host headers. LiteLLM must be upgraded to version 1.83.7 or later (or ≥ 1.84.0 to address CVE-2026-59822). If testing interfaces are not required in production, disable MCP routes entirely by passing --disable_mcp_endpoints to the CLI or setting DISABLE_MCP_REST=True in container environments.

Reverse Proxy Normalization

Edge proxies must inspect and normalize HTTP headers before traffic reaches ASGI application workers, stripping malformed delimiters:

server {
 listen 443 ssl http2;
 server_name litellm.internal.domain;

 # Drop requests with URI path delimiters in the Host header
 if ($http_host ~* "[\/\?\#\@\:]") {
 return 400 "Malformed Host Header";
 }

 # Block external reachability to internal MCP testing endpoints
 location ~* ^/mcp-rest/test/ {
 deny all;
 return 403;
 }

 location / {
 proxy_pass http://127.0.0.1:4000;
 proxy_set_header Host $host; # Explicitly forward normalized $host
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

Container Runtime Isolation

To block kernel register manipulation and local persistence, execute AI gateway workloads under hardened container security profiles. Enforcing readOnlyRootFilesystem: true, executing as a non-root UID, and revoking all Linux capabilities (drop: ["ALL"]) prevents the acquisition of CAP_SYS_RAWIO and CAP_SYS_ADMIN. These constraints stop unauthorized kernel module loading, neutralize persistence mechanisms, and secure the operational perimeter surrounding foundation model access.