GHSA-xqmj-j6mv-4862: LiteLLM RCE — HIGH

CISO Take

LiteLLM Proxy's `/prompts/test` endpoint renders user-supplied templates without sandboxing, allowing any holder of a valid proxy API key to execute arbitrary code directly on the host process. This is critical because LiteLLM functions as a centralized AI API gateway — the process environment typically contains provider credentials (OpenAI, Anthropic, Azure, etc.) and database connection strings, making credential mass-harvest the primary blast radius. The package carries a risk score of 79/100 with 19 prior CVEs on record, signaling a pattern of insecure design in a component many orgs trust with their entire AI provider key chain. No public exploit or KEV entry exists yet, but SSTI payloads against this endpoint type are well-documented and require no AI-specific knowledge — only a valid API key. Upgrade to litellm 1.83.7-stable immediately, or block `POST /prompts/test` at the API gateway and rotate all secrets in the proxy environment.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

HIGH. The vulnerability requires only a valid proxy API key to exploit — a bar that any developer, contractor, or holder of a leaked credential can clear. Server-side template injection (CWE-1336) via Jinja2 or similar engines is a well-understood attack class with widely available payloads requiring no AI knowledge. The combination of easy exploitation, full RCE capability, and a high-value credential store as the primary target makes this a critical finding for any org using LiteLLM as their AI gateway. The 79/100 package risk score and 19-CVE history indicate systemic security debt in this codebase. Insider threat and credential-leak scenarios elevate risk beyond external attacker scenarios.

How does the attack unfold?

Initial Access

Attacker obtains a valid LiteLLM proxy API key via credential leak, insider access, or existing authorized developer account.

AML.T0012

Exploitation

Crafted POST request to /prompts/test injects a server-side template injection (SSTI) payload into the unsandboxed template renderer endpoint.

AML.T0049

Code Execution

Template renderer evaluates attacker-controlled Python expressions, granting arbitrary command execution within the LiteLLM Proxy host process.

AML.T0050

Credential Harvest

Attacker dumps all process environment variables, extracting every provider API key (OpenAI, Anthropic, Azure) and database credential stored in the proxy for downstream abuse.

AML.T0055

Initial Access

Attacker obtains a valid LiteLLM proxy API key via credential leak, insider access, or existing authorized developer account.

AML.T0012

Exploitation

Crafted POST request to /prompts/test injects a server-side template injection (SSTI) payload into the unsandboxed template renderer endpoint.

AML.T0049

Code Execution

Template renderer evaluates attacker-controlled Python expressions, granting arbitrary command execution within the LiteLLM Proxy host process.

AML.T0050

Credential Harvest

Attacker dumps all process environment variables, extracting every provider API key (OpenAI, Anthropic, Azure) and database credential stored in the proxy for downstream abuse.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	>= 1.80.5, < 1.83.7	`1.83.7`
51.0K OpenSSF 6.1 6 dependents Pushed 3d ago 44% patched ~38d 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

Trivial

What should I do?

6 steps

Patch immediately: upgrade litellm to >= 1.83.7-stable.
If patching is delayed: block POST /prompts/test at your reverse proxy or API gateway — this endpoint is not required for production inference traffic.
Rotate all secrets in the LiteLLM process environment: provider API keys (OpenAI, Anthropic, Azure, etc.), database credentials, and any other sensitive env vars.
Audit access logs for POST requests to /prompts/test since April 24, 2026 (disclosure date) to detect potential exploitation.
Implement least-privilege API key scoping so that inference-only keys cannot access prompt management routes.
Review who holds proxy API keys in your deployment and revoke stale or unnecessary credentials.

How is it classified?

Code Execution Data Extraction Inference API AML.T0012 - Valid Accounts AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application 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

8.4 - AI system risk management

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place to sustain the value of deployed AI systems

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure LLM05:2025 - Improper Output Handling

Frequently Asked Questions

What is GHSA-xqmj-j6mv-4862?

LiteLLM Proxy's `/prompts/test` endpoint renders user-supplied templates without sandboxing, allowing any holder of a valid proxy API key to execute arbitrary code directly on the host process. This is critical because LiteLLM functions as a centralized AI API gateway — the process environment typically contains provider credentials (OpenAI, Anthropic, Azure, etc.) and database connection strings, making credential mass-harvest the primary blast radius. The package carries a risk score of 79/100 with 19 prior CVEs on record, signaling a pattern of insecure design in a component many orgs trust with their entire AI provider key chain. No public exploit or KEV entry exists yet, but SSTI payloads against this endpoint type are well-documented and require no AI-specific knowledge — only a valid API key. Upgrade to litellm 1.83.7-stable immediately, or block `POST /prompts/test` at the API gateway and rotate all secrets in the proxy environment.

Is GHSA-xqmj-j6mv-4862 actively exploited?

No confirmed active exploitation of GHSA-xqmj-j6mv-4862 has been reported, but organizations should still patch proactively.

How to fix GHSA-xqmj-j6mv-4862?

1. Patch immediately: upgrade litellm to >= 1.83.7-stable. 2. If patching is delayed: block POST /prompts/test at your reverse proxy or API gateway — this endpoint is not required for production inference traffic. 3. Rotate all secrets in the LiteLLM process environment: provider API keys (OpenAI, Anthropic, Azure, etc.), database credentials, and any other sensitive env vars. 4. Audit access logs for POST requests to /prompts/test since April 24, 2026 (disclosure date) to detect potential exploitation. 5. Implement least-privilege API key scoping so that inference-only keys cannot access prompt management routes. 6. Review who holds proxy API keys in your deployment and revoke stale or unnecessary credentials.

What systems are affected by GHSA-xqmj-j6mv-4862?

This vulnerability affects the following AI/ML architecture patterns: LLM proxy/gateway deployments, RAG pipelines, agent frameworks, multi-provider AI routing, model serving infrastructure.

What is the CVSS score for GHSA-xqmj-j6mv-4862?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM proxy/gateway deploymentsRAG pipelinesagent frameworksmulti-provider AI routingmodel serving infrastructure

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM02:2025, LLM05:2025

What are the technical details?

Original Advisory

### Impact The `POST /prompts/test` endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. Proxy deployments running an affected version are in scope. ### Patches The issue is fixed in **`1.83.7-stable`**. The fix switches the prompt template renderer to a sandboxed environment that blocks the attributes this attack relies on. LiteLLM recommends upgrading to `1.83.7-stable` or later. ### Workarounds If upgrading is not immediately possible: 1. Block `POST /prompts/test` at your reverse proxy or API gateway. 2. Review and rotate API keys that should not have access to prompt management routes.

Exploitation Scenario

An adversary with a valid LiteLLM proxy API key — obtained via a leaked .env file, a disgruntled employee, or simply as a developer with authorized access — sends a crafted POST request to `/prompts/test` with a Jinja2 SSTI payload in the template body (e.g., accessing `config.__class__.__init__.__globals__['os'].environ`). The unpatched endpoint passes this template directly to the renderer without sandboxing. The renderer evaluates the Python expression and returns all environment variables in the response, immediately yielding every provider API key stored in the proxy. The attacker then uses harvested OpenAI or Anthropic keys to run queries at the victim's expense, exfiltrate conversation data from connected applications, or pivot to databases via exposed connection strings. No privilege escalation, no AI knowledge, and no user interaction are required.

Weaknesses (CWE)

CWE-1336 Improper Neutralization of Special Elements Used in a Template Engine Primary

CWE-1336 — Improper Neutralization of Special Elements Used in a Template Engine: The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

[Architecture and Design] Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands.
[Implementation] Use the template engine's sandbox or restricted mode, if available.

Source: MITRE CWE corpus.