Blog Published: Jul 2, 2026

LiteLLM Control Plane Is Being Hit in the Wild

Zenity reported active exploitation attempts against two LiteLLM 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
LiteLLM administrative and test endpoints should require strong service or admin identity. Real authentication does not patch either CVE by itself, but it sharply reduces who can reach the guardrail tester or connection-test control plane in the first place.
AID-H-026.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-034.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-D-005.002
Security Monitoring & Alerting for AI
High
Detection should be route-specific: calls to /guardrails/test_custom_code, Python bytecode or os.environ payloads, nested api_base, environment-reference strings, and unusual outbound destinations all deserve high-confidence alerts.
AID-E-001.002
Automated & Real-time Invalidation
High
If a master key or provider key may have been sent to an attacker-controlled endpoint, manual rotation is too slow. Alert-driven invalidation should disable exposed keys and force new credentials through the approved secret-management path.
AID-E-004
Post-Eviction System Patching & Hardening
High
Both paths ultimately require patching and proof. Upgrade LiteLLM, remove root execution, close the unsafe validation paths, codify detections, and replay the original guardrail and connection-test payloads in an isolated clone before considering the incident closed.

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.