Incident Published: Jul 2, 2026

LiteLLM Control Plane Is Being Hit in the Wild

Zenity reported active exploitation attempts against two LiteLLM (an AI gateway for routing LLM requests) control-plane paths: the custom-code guardrail tester and the connection-test API. Together they show why an AI gateway is a critical asset: it sits near provider keys, routing policy, sandboxed code execution, and the model traffic every application depends on.

Remote Code ExecutionCredential TheftRuntime IsolationCredential GovernanceAPI Routers
9 applicable AIDEFEND defenses
Source: What You Don't Know Can Hurt You: Why AI Security Research Needs to Move Out of the Lab and Into the Wild 
Authors: Ayush RoyChowdhury & Avishai Efrat
Original article: Jun 30, 2026, 1:41 PM

Threat Analysis

  • The guardrail tester path turns a helper feature into RCE. Zenity saw POST requests to /guardrails/test_custom_code carrying Python probes and CVE-2026-40217 sandbox-escape payloads. In the standard root-running proxy image, escape could become root-level code execution inside the container.
  • The connection-test path turns routing flexibility into key exfiltration. Attackers sent /health/test_connection requests with attacker-controlled api_base nested under litellm_params, plus api_key values referencing server-side secrets such as LITELLM_MASTER_KEY.
  • This is an AI gateway control-plane issue. A compromised LiteLLM gateway may expose model-provider credentials, route decisions, test endpoints, and administrative paths shared by downstream AI apps.
  • The fixes span patching and architecture. Teams need updated LiteLLM versions, non-root containers, restricted code execution, default-deny egress, route policies that cannot be supplied by request parameters, and fast key invalidation.

Applicable AIDEFEND Defenses (9)

AID-H-004.002
Service & API Authentication
Very High
At the LiteLLM API or gateway, authenticate the calling service, workload, application, or external integration before delivering requests to guardrail-tester and connection-test endpoints. This machine-authentication control does not patch either CVE, authorize a valid identity, or govern human administrator access under AID-H-004.001.
AID-H-025.002
Safe Interpreter Enforcement
Very High
The guardrail tester is a dynamic-code boundary. Restricted interpreter enforcement, deny-by-default execution gateways, and ephemeral execution environments directly reduce the chance that custom Python can reach filesystem, network, or privileged APIs.
AID-I-001.001
Container-Based Isolation
Very High
Zenity specifically called out root execution in the official LiteLLM Docker path. Non-root containers, dropped capabilities, read-only filesystems, and security contexts reduce the blast radius if code execution lands inside the proxy.
AID-I-001.004
Sandbox Network Egress Restrictions
High
If guardrail code execution succeeds, default-deny sandbox egress blocks reverse shells and secret exfiltration callbacks. This is also a useful last line of defense when exploit prevention fails.
AID-I-002.002
Secure External AI Service Connectivity
High
The connection-test attack needs LiteLLM to call an attacker-controlled api_base. Default-deny egress, DNS/SNI allowlists, and governed outbound gateways directly prevent arbitrary destinations from receiving provider or master keys.
AID-H-033.004
Route Policy Bundle Versioning, Approval, Canary & Rollback
High
Model provider destinations and route policies should be reviewed security artifacts, not request-supplied strings inside a health check. Moving destinations into approved route bundles removes the nested api_base abuse pattern from normal runtime input.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
High
Reconcile deployed LiteLLM versions with both exploited control-plane CVEs, rebuild the fixed release, deploy it through drained canary and staged rings, and verify by digest-level fleet readback that no vulnerable proxy remains. This owns the patch lifecycle for both paths.
AID-E-001.001
Root & Long-Lived Credential Object Eviction
High
If the LiteLLM master key or an upstream provider API key may have been sent to an attacker-controlled endpoint, manual rotation is too slow. Alert-driven eviction should revoke and rotate those long-lived credential objects at their authoritative issuer, force new secrets through the approved secret-management path, and remove any attacker-created keys - because exposed master and provider API keys are long-lived credential objects, not issued sessions.
AID-E-004
Incident Exploit-Path Closure Verification
High
After the fixed LiteLLM release and compensating controls are deployed, independently replay the original guardrail-tester and nested api_base payloads in an isolated clone and prove both paths fail across the incident-scoped population. This is closure proof, not the upgrade owner.

What Defenders Should Do Now

  • Identify every LiteLLM proxy and record version, exposed interfaces, auth mode, admin routes, container user, configured master key, and egress policy.
  • Upgrade away from versions affected by CVE-2026-40217 and the nested api_base connection-test behavior. Treat AI gateway patching as a high-priority production change.
  • Disable or tightly restrict custom-code guardrail testing in production. If it must exist, run it in a non-root, short-lived, restricted interpreter or microVM environment with no production secrets and default-deny egress.
  • Block request-controlled provider destinations. Approved model endpoints should come from reviewed route policy, not from arbitrary api_base values in user or admin request payloads.
  • Search logs for /guardrails/test_custom_code, /health/test_connection, litellm_params.api_base, os.environ, LITELLM_MASTER_KEY, and outbound calls from LiteLLM to unfamiliar domains. Rotate keys if exposure cannot be ruled out.

Conclusion

LiteLLM is not just a convenience proxy. In many deployments it is the place where model routing, provider credentials, policy checks, budget control, and developer test functions meet. That makes the gateway a critical asset: patch it quickly, isolate its execution paths, constrain its egress, and treat every exposed admin feature as part of the AI control plane.