LiteLLM AI Gateway — Unauthenticated Remote Code Execution

LiteLLM is a widely deployed open-source AI gateway / proxy that exposes many LLM providers behind one OpenAI-compatible API. Two of its Model Context Protocol (MCP) preview endpoints — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accept a full stdio server config (command, args, env) and, when invoked, spawn the supplied command as a subprocess under the proxy process user. In vulnerable builds these endpoints have no admin-role gate, so any holder of a proxy API key can run arbitrary commands (CVE-2026-42271, CVSS 8.7).

Horizon3.ai demonstrated that the command injection chains with CVE-2026-48710 — a Host-header validation bypass ("BadHost") in the Starlette web framework (CVSS 6.5) — to reach the admin-scoped endpoints without authentication from any network-reachable host. The combined chain is CVSS 10.0. CISA added CVE-2026-42271 to the KEV catalog on 2026-06-08 citing active in-the-wild exploitation, and public PoCs exist.

Attacker objective: code execution on the gateway host to harvest the crown jewels an AI gateway holds — provider API keys injected as environment variables (OpenAI, Anthropic, Azure, AWS Bedrock), mounted secret files, and the LiteLLM config/database — then pivot outward with a reverse shell or dropped tooling.

Highest-value defensive angle: the gateway is a Python service. A LiteLLM parent (python/uvicorn/gunicorn) spawning a shell, network client, or interpreter is never normal and is the cleanest, lowest-FP detection in this pack (Q1–Q3). Because atomic network IOCs are not published, hunt on this process-lineage behavior rather than IPs/hashes.

Defender priority: Patch LiteLLM to 1.83.7+ and Starlette to 1.0.1+, block the two /mcp-rest/test/* endpoints at the ingress today, then hunt Q1–Q3 for any python/uvicorn process that has already spawned a shell — and rotate every provider key the proxy could read.

Intel gap: No public campaign has released atomic network IOCs (C2 IPs, payload hashes). This pack therefore leads with behavioral/process-lineage detection and configuration indicators, and uses REPLACE_WITH_… placeholders in the IOC CSV rather than fabricated values.

Hunt hypotheses (fidelity-ordered)

Attack chain

No atomic network IOCs (C2 IPs, payload hashes) have been published for this activity. The indicators below are exploit-path, configuration, and behavioral signals — use them as hunts, not blocklist entries, until campaign-specific atomics are sourced.

Telemetry note: the strongest detections here need the Falcon Linux sensor running inside the LiteLLM container (or on the host with container visibility). Confirm sensor coverage on AI/ML infrastructure before trusting Q1–Q5.

Where the Falcon sensor is not inside the container, the exploit still leaves a trail at the ingress / reverse proxy and in LiteLLM's own logs. Run these against whatever platform holds those logs (NGSIEM, ELK, cloud LB logs, WAF).

Reverse-proxy / ingress access log — exploit endpoints & host-header bypass

// Any HTTP method to the MCP test endpoints is suspicious in production:
request.path in ("/mcp-rest/test/connection", "/mcp-rest/test/tools/list")

// Host-header bypass (CVE-2026-48710): Host value not matching your served FQDN(s)
http.host NOT IN ("gateway.example-allowed-fqdn") AND status_code < 500

// Triage: source IP, count, first/last seen, request body size (large body = stdio config payload)

LiteLLM application log

// Look for MCP "test connection" / "tools list" invocations and any subprocess-spawn log lines.
// Correlate their timestamps against the ProcessRollup2 hits from Q1-Q3 on the same host.

Kubernetes / container runtime

// If runtime audit is enabled, alert on 'exec into' or process creation inside the
// litellm pod where the exec'd binary is a shell (sh, bash) - the pod should never run one.

These native hunts are the primary coverage for Step 2 (host-header bypass), which produces no endpoint process telemetry. Treat any hit here as a trigger to pull Q1–Q3 for the same host/timeframe.

Deployment path: promote Q1/Q3 first — they are low-FP and map cleanly to a parent/child image-name IOA. Scope IOAs to a host group tagged for AI/ML infrastructure so the (rare) legitimate shell-spawning services elsewhere aren't affected.

No campaign atomics are published. The CSV uses REPLACE_WITH_… placeholders — populate only from IOCs you source and cite. Ship the behavioral and audit blocks now; they need no atomics.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_SHA256,prevent,critical,2027-01-14,LiteLLM RCE payload,campaign:LiteLLM-RCE
ipv4,REPLACE_WITH_C2_IP,detect,high,2026-10-14,LiteLLM RCE C2,campaign:LiteLLM-RCE
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-10-14,LiteLLM RCE C2,campaign:LiteLLM-RCE

# Parent -> Child image (all high fidelity on a gateway host):
python|uvicorn|gunicorn|litellm  ->  sh|bash|dash|zsh
python|uvicorn|gunicorn|litellm  ->  curl|wget|nc|ncat|socat
# CommandLine markers:
/dev/tcp/    bash -i    nc -e    python -c ...socket
/proc/self/environ    printenv    cat *.env    /run/secrets

# Flag any host where:
LiteLLM version in [1.74.2 .. 1.83.6]      # fixed in 1.83.7
Starlette version 1.0.0 or earlier         # fixed in 1.0.1
AND /mcp-rest/test/connection reachable pre-auth
# Confirm patched:
pip show litellm | grep -i version
python -c "import starlette,sys; sys.stdout.write(starlette.__version__)"

# nginx / reverse-proxy stop-gap if you cannot patch immediately:
location = /mcp-rest/test/connection { return 403; }
location = /mcp-rest/test/tools/list { return 403; }
# Enforce a Host allow-list to blunt CVE-2026-48710:
if ($host != "gateway.your-fqdn.example") { return 421; }

1 · Patch & verify (Python / container)

# Pin the fixed versions and rebuild the image:
pip install "litellm==1.83.7" "starlette>=1.0.1"     # or a later release
# Verify at runtime:
pip show litellm | grep -i version         # expect 1.83.7 or later
python -c "import starlette,sys; sys.stdout.write(starlette.__version__)"
# Confirm the test endpoints now require admin (expect 401/403 unauth):
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:4000/mcp-rest/test/connection

2 · Reverse-proxy stop-gap (nginx) — until patched

location = /mcp-rest/test/connection { return 403; }
location = /mcp-rest/test/tools/list { return 403; }
# Host allow-list to blunt CVE-2026-48710:
map $host $bad_host { default 1; "gateway.your-fqdn.example" 0; }
if ($bad_host) { return 421; }

3 · Kubernetes hardening (gateway Deployment)

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities: { drop: ["ALL"] }
  seccompProfile: { type: RuntimeDefault }
---
# NetworkPolicy: egress only to known provider endpoints (example — tune to your providers)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: litellm-egress-allowlist }
spec:
  podSelector: { matchLabels: { app: litellm } }
  policyTypes: ["Egress"]
  egress:
    - to: [{ ipBlock: { cidr: 0.0.0.0/0 } }]   # REPLACE with provider CIDRs
      ports: [{ protocol: TCP, port: 443 }]

4 · Provider key rotation checklist

# For each provider whose key was in the gateway env/config:
#  1. Issue a new key in the provider console.
#  2. Update the secrets manager entry (NOT the container env).
#  3. Revoke the old key.
#  4. Review provider usage/billing logs for anomalous calls since the exposure window.

Known gaps: (1) Step 2 (host-header bypass) has no endpoint process telemetry — coverage depends on ingress/WAF logs being onboarded (s7). (2) Minimal/distroless AI containers frequently lack the Falcon sensor, blinding Q1–Q5 — confirm sensor coverage first (see Validation Gates). (3) Egress detection (Q4) is FP-prone because the proxy legitimately calls providers on 443; allow-list provider CIDRs to sharpen it.

Generated 2026-07-14 · HuntPack · Defensive detection & hardening content only.