CVE-2026-59821: 
NixOS vulnerability analysis and mitigation

CVE-2026-59821 is a code injection vulnerability in LiteLLM (an AI Gateway/proxy server for LLM APIs) that allows a privileged user to execute arbitrary Python code within the LiteLLM proxy environment. The vulnerability affects all LiteLLM versions prior to 1.82.0-stable, including the 1.82.0-nightly build. It was first published on June 30, 2026 (GitHub advisory) and disclosed via NVD on July 8, 2026. The CVSS v3.1 base score is 7.2 (High), while the CVSS v4.0 base score is 2.1 (Low) (Github Advisory, Red Hat Advisory).

The root cause is CWE-94 (Improper Control of Generation of Code / Code Injection): the production POST /guardrails and PUT /guardrails/{guardrail_id} endpoints accepted custom Python code submissions without applying the sandboxing and pattern-based validation that was present in the test endpoint (Github Advisory). An attacker with administrative access (or, in deployments lacking a configured LITELLM_MASTER_KEY, any caller treated as a proxy admin) could submit malicious Python code via these guardrail management endpoints, which would then execute directly in the LiteLLM proxy process without restriction (GitHub Security Advisory). The fix (commit e50b448) centralized code validation into a new code_validator.py module and enforced PROXY_ADMIN role checks on all guardrail create/update/delete/patch endpoints, and also corrected an authentication bypass where unauthenticated callers were incorrectly assigned PROXY_ADMIN role instead of INTERNAL_USER when no master key was set (GitHub Commit).

Successful exploitation allows arbitrary Python code execution within the LiteLLM proxy container, enabling an attacker to read environment variables and process secrets (such as API keys for LLM providers), modify proxy behavior, or disrupt service availability. The vulnerability also poses a risk of information disclosure, as any secrets accessible to the proxy process — including upstream LLM API credentials — could be exfiltrated. In deployments without a master key configured, the effective attack surface is broader, as unauthenticated callers may be granted administrative privileges, making the vulnerability reachable without intended authorization (Github Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and NVD's SSVC assessment rates exploitation as "none" with technical impact as "partial" (Red Hat Advisory). The EPSS score is approximately 0.29–0.36%, placing it in roughly the 28th percentile for exploitation likelihood within 30 days. Exploitation requires high privileges (or a misconfigured deployment lacking a master key), and the attack is not automatable according to NVD's assessment.

1. Reconnaissance: Identify a LiteLLM proxy instance running a version prior to 1.82.0-stable. Check whether LITELLM_MASTER_KEY is configured — if not, any caller may be treated as a proxy administrator.
2. Obtain or abuse admin credentials: If a master key is set, obtain valid admin credentials. If no master key is configured, proceed without authentication, as the proxy may grant PROXY_ADMIN role by default.
3. Craft malicious guardrail payload: Prepare a JSON payload for the POST /guardrails endpoint containing a custom_code field with arbitrary Python code (e.g., reading environment variables: import os; result = os.environ.copy()).
4. Submit the payload: Send an HTTP POST request to /guardrails (or PUT to /guardrails/{guardrail_id}) with the malicious custom_code field. Unlike the test endpoint, these production paths did not apply sandboxing or forbidden-pattern validation in vulnerable versions.
5. Trigger code execution: The submitted Python code executes within the LiteLLM proxy process upon guardrail creation/update, allowing the attacker to exfiltrate secrets, establish persistence, or disrupt the service (Github Advisory, GitHub Commit).

• Network: Unexpected or unauthorized HTTP POST requests to /guardrails or PUT requests to /guardrails/{guardrail_id} from unusual source IPs or at unusual times; outbound connections from the LiteLLM proxy container to external hosts not associated with configured LLM providers.
• Logs: LiteLLM proxy access logs showing guardrail creation or update events by non-administrative accounts or unauthenticated callers; absence of LITELLM_MASTER_KEY in configuration combined with guardrail management activity.
• Process: Unexpected child processes spawned by the LiteLLM Python process (e.g., shell commands, network utilities); unusual memory or CPU spikes in the proxy container following guardrail API calls.
• File System: New or modified files within the LiteLLM proxy container directory created by the proxy process user; unexpected scripts or credential files written to disk.

Upgrade LiteLLM to version 1.82.0-stable or later, which applies code validation and enforces PROXY_ADMIN role checks on all guardrail management endpoints (Github Advisory, LiteLLM Release). If immediate upgrade is not possible, apply the following workarounds: (1) restrict access to POST /guardrails and PUT /guardrails/{guardrail_id} to trusted administrators only via network controls or API gateway policies; (2) ensure LITELLM_MASTER_KEY is configured to prevent unauthenticated callers from being granted admin privileges; and (3) disable Custom Code Guardrails for untrusted users. Additionally, review audit logs for any unauthorized guardrail modifications in versions prior to 1.82.0-stable.