CVE-2026-59821: LiteLLM code exec — LOW

CISO Take

LiteLLM, a widely deployed AI gateway that proxies calls to OpenAI-compatible LLM APIs, shipped its Custom Code Guardrails feature with a security gap: the production create/update endpoints skipped the sandboxing and validation applied to the test endpoint, so a privileged user allowed to manage guardrails could submit Python that executed directly in the proxy process and could expose any secrets available to that process — API keys, database credentials, upstream LLM provider tokens. There's no public exploit, no CISA KEV listing, and no EPSS score published, so this reads as an insider-privilege-escalation risk rather than an internet-scale threat, but the blast radius is high because LiteLLM proxies sit in front of every LLM call an organization makes and typically hold the credentials for all of them. Any org running self-hosted LiteLLM with guardrail-authoring permissions delegated beyond a small trusted admin group should treat this as urgent, since the barrier to exploitation is simply having that one role, not a technical exploit chain. Patch to 1.82.0-stable immediately; until then, restrict guardrail create/update permissions to fully trusted admins only and audit recent guardrail changes for anomalous Python payloads or unexpected outbound network calls from the proxy process.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Moderate-to-high risk for organizations self-hosting LiteLLM as an AI gateway. The vulnerability requires a privileged role (guardrail create/update access) to exploit, which limits exposure primarily to malicious or compromised insiders and over-provisioned admin accounts rather than anonymous attackers. However, the impact ceiling is severe: arbitrary Python execution inside the proxy process gives access to every secret the process can reach, including upstream LLM provider API keys, database credentials, and any environment secrets — a single compromise can cascade into full compromise of every LLM integration behind the gateway. No public PoC, scanner template, or KEV listing exists as of publication, so opportunistic mass exploitation is unlikely; the primary risk vector is privilege abuse or lateral movement following a separate account compromise.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a privileged LiteLLM account with permission to create or update Custom Code Guardrails.

AML.T0012

Exploitation

Attacker submits malicious Python via the production guardrail create/update endpoint, which lacks the sandboxing applied to the test endpoint.

AML.T0050

Credential Access

The unsandboxed code executes in the proxy process and reads secrets available to it, such as upstream LLM API keys and database credentials.

AML.T0055

Impact

Attacker exfiltrates or abuses the harvested secrets to pivot into other systems or run up costs on connected LLM provider accounts.

AML.T0025

Initial Access

Attacker obtains or already holds a privileged LiteLLM account with permission to create or update Custom Code Guardrails.

AML.T0012

Exploitation

Attacker submits malicious Python via the production guardrail create/update endpoint, which lacks the sandboxing applied to the test endpoint.

AML.T0050

Credential Access

The unsandboxed code executes in the proxy process and reads secrets available to it, such as upstream LLM API keys and database credentials.

AML.T0055

Impact

Attacker exfiltrates or abuses the harvested secrets to pivot into other systems or run up costs on connected LLM provider accounts.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	—	No patch
52.6K OpenSSF 6.0 6 dependents Pushed 3d ago 43% patched ~49d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to LiteLLM 1.82.0-stable or later immediately, which restores sandboxing/validation parity between the guardrail test and production create/update paths. Until patched, restrict guardrail create/update permissions to a minimal, fully trusted admin set — treat this role as equivalent to code-deploy access. Rotate any secrets accessible to the LiteLLM proxy process (upstream API keys, DB credentials) if untrusted or broadly-provisioned users had guardrail-admin access prior to patching. Audit guardrail configuration change history for unexpected Python payloads, and monitor proxy process logs for anomalous outbound connections or file/env access following guardrail updates as a detection signal.

How is it classified?

Code Execution Data Leakage Framework API Plugin AML.T0012 - Valid Accounts AML.T0050 - Command and Scripting Interpreter AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

Annex A.6.2 - AI system security controls

NIST AI RMF

MANAGE-4.1 - Post-deployment monitoring for AI system risks and vulnerabilities

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-59821?

LiteLLM, a widely deployed AI gateway that proxies calls to OpenAI-compatible LLM APIs, shipped its Custom Code Guardrails feature with a security gap: the production create/update endpoints skipped the sandboxing and validation applied to the test endpoint, so a privileged user allowed to manage guardrails could submit Python that executed directly in the proxy process and could expose any secrets available to that process — API keys, database credentials, upstream LLM provider tokens. There's no public exploit, no CISA KEV listing, and no EPSS score published, so this reads as an insider-privilege-escalation risk rather than an internet-scale threat, but the blast radius is high because LiteLLM proxies sit in front of every LLM call an organization makes and typically hold the credentials for all of them. Any org running self-hosted LiteLLM with guardrail-authoring permissions delegated beyond a small trusted admin group should treat this as urgent, since the barrier to exploitation is simply having that one role, not a technical exploit chain. Patch to 1.82.0-stable immediately; until then, restrict guardrail create/update permissions to fully trusted admins only and audit recent guardrail changes for anomalous Python payloads or unexpected outbound network calls from the proxy process.

Is CVE-2026-59821 actively exploited?

No confirmed active exploitation of CVE-2026-59821 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59821?

Upgrade to LiteLLM 1.82.0-stable or later immediately, which restores sandboxing/validation parity between the guardrail test and production create/update paths. Until patched, restrict guardrail create/update permissions to a minimal, fully trusted admin set — treat this role as equivalent to code-deploy access. Rotate any secrets accessible to the LiteLLM proxy process (upstream API keys, DB credentials) if untrusted or broadly-provisioned users had guardrail-admin access prior to patching. Audit guardrail configuration change history for unexpected Python payloads, and monitor proxy process logs for anomalous outbound connections or file/env access following guardrail updates as a detection signal.

What systems are affected by CVE-2026-59821?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways, guardrails / safety layers, agent frameworks, model serving.

What is the CVSS score for CVE-2026-59821?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM API gatewaysguardrails / safety layersagent frameworksmodel serving

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0050 Command and Scripting Interpreter

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6.2

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM's Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable.

Exploitation Scenario

An internal user or contractor with guardrail-management privileges in a self-hosted LiteLLM deployment — perhaps granted broadly because the org assumed guardrail authoring was low-risk configuration work — submits a 'custom code guardrail' containing Python that reads process environment variables and exfiltrates them to an external endpoint. Because the production create/update path doesn't sandbox the code the way the test endpoint does, the payload executes with the proxy's full privileges the moment the guardrail is saved or activated. The attacker now holds the LLM provider API keys and any other secrets available to the proxy, enabling downstream abuse such as running up API costs, exfiltrating data from other integrations sharing the same keys, or pivoting further into the environment.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.