CVE-2026-59821: LiteLLM Proxy Server RCE Vulnerability

CVE-2026-59821 Overview

CVE-2026-59821 affects LiteLLM, a proxy server (AI Gateway) that routes calls to large language model APIs using the OpenAI or native format. Versions prior to 1.82.0-stable fail to apply the same sandboxing and validation on the Custom Code Guardrails production create and update paths that the test endpoint enforces. A privileged user with permission to create or update guardrails can submit custom Python code that executes inside the LiteLLM proxy process. The executing code can access secrets held by the proxy environment, including API keys and credentials. The issue is tracked under CWE-94: Improper Control of Generation of Code.

Critical Impact
Authenticated privileged users can execute arbitrary Python inside the LiteLLM proxy runtime and exfiltrate secrets from the process environment.

Affected Products

LiteLLM proxy server versions prior to 1.82.0-stable
Deployments exposing the Custom Code Guardrails create and update API paths
LiteLLM instances configured with privileged administrative accounts

Discovery Timeline

2026-07-08 - CVE-2026-59821 published to NVD
2026-07-08 - Last updated in NVD database
Fixed release - LiteLLM v1.82.0-stable published on GitHub Releases with advisory GHSA-72m8-9m7m-h278

Technical Details for CVE-2026-59821

Vulnerability Analysis

LiteLLM supports a Custom Code Guardrail feature that lets administrators define Python logic to inspect and filter prompts or model responses. The test endpoint runs submitted code through a validator that blocks dangerous constructs. The production create and update endpoints skipped that validation before version 1.82.0-stable. A privileged user submitting a guardrail through the production paths could therefore include Python that reads environment variables, imports arbitrary modules, and issues outbound network calls from the proxy host. The impact is bounded by the requirement that the attacker already hold guardrail management privileges.

Root Cause

The root cause is inconsistent input validation between the guardrail test path and the production create and update paths. Only the test endpoint invoked the sandbox and pattern-based validator, so equivalent code submitted through the persistent API paths bypassed all restrictions and reached the runtime executor unchecked.

Attack Vector

An attacker with the guardrail administrative role authenticates to the LiteLLM proxy and issues an API request to create or update a Custom Code Guardrail. The request body contains Python source that references dangerous builtins such as open, exec, or __import__, or reads secrets from os.environ. LiteLLM stores and later executes the guardrail during request processing, running the attacker's code with the privileges of the proxy process.

python

# Patch excerpt: litellm/proxy/guardrails/guardrail_hooks/custom_code/code_validator.py
# Source: https://github.com/BerriAI/litellm/commit/e50b4486d0f7aa0497185a1ebcdd2c91f1769eba
import re
from typing import List, Tuple

# Security validation patterns
FORBIDDEN_PATTERNS: List[Tuple[str, str]] = [
    # Import statements
    (r"\bimport\s+", "import statements are not allowed"),
    (r"\bfrom\s+\w+\s+import\b", "from...import statements are not allowed"),
    (r"__import__\s*\(", "__import__() is not allowed"),
    # Dangerous builtins
    (r"\bexec\s*\(", "exec() is not allowed"),
    (r"\beval\s*\(", "eval() is not allowed"),
    (r"\bcompile\s*\(", "compile() is not allowed"),
    (r"\bopen\s*\(", "open() is not allowed"),
    (r"\bgetattr\s*\(", "getattr() is not allowed"),
    (r"\bsetattr\s*\(", "setattr() is not allowed"),
    (r"\bdelattr\s*\(", "delattr() is not allowed"),
    (r"\bglobals\s*\(", "globals() is not allowed"),
    (r"\blocals\s*\(", "locals() is not allowed"),
    (r"\bvars\s*\(", "vars() is not allowed"),
    (r"\bdir\s*\(", "dir() is not allowed"),
    (r"\bbreakpoint\s*\(", "breakpoint() is not allowed"),
    (r"\binput\s*\(", "input() is not allowed"),
    # Dangerous dunder access
    (r"__builtins__", "__builtins__ access is not allowed"),
    (r"__globals__", "__globals__ access is not allowed"),
    (r"__code__", "__code__ access is not allowed"),
    (r"__subclasses__", "__subclasses__ access is not allowed"),
    (r"__bases__", "__bases__ access is not allowed"),
    (r"__mro__", "__mro__ access is not allowed"),
]

Source: GitHub commit e50b448. The fix introduces a shared validator that both the test and production paths must invoke before persisting or executing custom guardrail code.

Detection Methods for CVE-2026-59821

Indicators of Compromise

Guardrail create or update API calls containing Python keywords such as import, exec, open, or __import__ in the request body.
Unexpected outbound network connections initiated by the LiteLLM proxy process to attacker-controlled hosts.
Guardrail records in the LiteLLM database containing code that references os.environ, credential paths, or subprocess primitives.
Proxy process access to files outside the LiteLLM working directory, including /etc/passwd, cloud metadata endpoints, or SSH key paths.

Detection Strategies

Audit LiteLLM admin API logs for POST and PUT requests targeting Custom Code Guardrail endpoints and inspect the payloads for restricted patterns.
Baseline the LiteLLM process behavior and alert on new child processes, unexpected file reads, or new outbound destinations.
Compare stored guardrail definitions against the FORBIDDEN_PATTERNS regex list introduced in v1.82.0-stable to flag pre-existing malicious entries.

Monitoring Recommendations

Forward LiteLLM proxy logs, admin action logs, and host process telemetry to a central analytics tier for correlation.
Monitor changes to guardrail configuration tables in the backing database and alert on modifications outside change windows.
Track secret and API key usage patterns from the LiteLLM host to detect anomalous outbound calls that follow guardrail changes.

How to Mitigate CVE-2026-59821

Immediate Actions Required

Upgrade LiteLLM to v1.82.0-stable or later using the GitHub release notes as a reference.
Review all existing Custom Code Guardrails and remove any that contain imports, dangerous builtins, or dunder attribute access.
Rotate any secrets, API keys, and provider credentials that were reachable from the LiteLLM proxy environment prior to the upgrade.
Restrict guardrail administrative permissions to a minimal set of trusted operators and enforce multi-factor authentication on those accounts.

Patch Information

The fix is delivered in LiteLLM v1.82.0-stable. Commit e50b4486d0f7aa0497185a1ebcdd2c91f1769eba adds code_validator.py with a shared FORBIDDEN_PATTERNS list and enforces validation on both the test and production create/update paths. See GHSA-72m8-9m7m-h278 for the vendor advisory.

Workarounds

Disable the Custom Code Guardrail feature at the proxy configuration level until the upgrade is deployed.
Place the LiteLLM admin API behind an authenticated reverse proxy that blocks guardrail create and update endpoints for non-privileged networks.
Run the LiteLLM proxy under a dedicated low-privilege service account with no access to unrelated secrets or cloud instance metadata.

bash

# Configuration example: pin LiteLLM to the fixed version
pip install --upgrade 'litellm==1.82.0'

# Verify the installed version
python -c "import litellm; print(litellm.__version__)"