LiteLLM Custom Code Guardrails Sandbox Bypass Leading to RCE

Technical Analysis

LiteLLM proxy exposes POST /guardrails and PUT /guardrails/{guardrail_id} endpoints that allow privileged users to define Custom Code Guardrails, which are meant to run in a sandboxed evaluation path similar to the test endpoint. The production create/update paths failed to apply equivalent validation and sandboxing, so submitted Python code executed directly in the proxy's runtime environment. Because the proxy can treat unauthenticated or low-privilege callers as admins when LITELLM_MASTER_KEY is unset, the effective entry point requires no genuine authorization, turning a guardrail-configuration feature into an arbitrary code execution primitive. Successful exploitation grants the attacker code execution within the LLM gateway process, exposing API keys, model credentials, and any other secrets accessible to that process, and could be leveraged to manipulate all traffic and guardrail decisions flowing through the proxy for downstream agents/models.

Affected Systems

LiteLLM

Detection Signatures

• Unexpected POST /guardrails or PUT /guardrails/{guardrail_id} requests containing Python code payloads (e.g., import os, subprocess, socket, eval/exec constructs) from non-admin or unauthenticated sessions
• Proxy logs showing guardrail creation/update without prior authentication when LITELLM_MASTER_KEY is unset
• Outbound network connections or file system access originating from the LiteLLM proxy process shortly after a guardrail create/update call
• Presence of custom_code guardrail configs referencing unusual imports or system-level calls

Remediation Steps

1. 1

   Upgrade LiteLLM

   Update to litellm 1.82.0-stable or later, which fixes the sandboxing gap in Custom Code Guardrails production endpoints.

2. 2

   Configure a master key

   Set LITELLM_MASTER_KEY so that requests are not implicitly treated as administrator-level, closing the authorization gap for these endpoints.

3. 3

   Restrict guardrail management endpoints

   Limit access to POST /guardrails and PUT /guardrails/{guardrail_id} to trusted administrators via network controls, API gateway policy, or RBAC.

4. 4

   Disable Custom Code Guardrails for untrusted users

   Avoid enabling the Custom Code Guardrails feature in multi-tenant or lower-trust deployments until upgraded and properly restricted.

5. 5

   Audit existing guardrail configs

   Review currently deployed custom code guardrails for unexpected or suspicious code that may have been injected prior to patching.