CVE-2026-12797: LiteLLM auth bypass

CISO Take

A low-privileged remote attacker can manipulate the prompt argument passed to litellm's enterprise banned keywords hook — the `async_pre_call_hook` function in `enterprise/enterprise_hooks/banned_keywords.py` — to bypass content authorization checks entirely in the Completions Interface. For organizations using litellm as an LLM API gateway with banned keyword lists as a compliance or data-loss control (e.g., blocking submission of PII, proprietary terms, or prohibited topics to external LLM providers), this control is rendered ineffective without any indication to defenders. A public exploit is already live on GitHub, dropping the exploitation bar to near-zero for any authenticated user, and litellm's track record of 32 CVEs in the same package with an OpenSSF scorecard of only 6.1/10 signals systemic security debt. Upgrade past 1.82.5 immediately; if patching is blocked, move keyword filtering enforcement upstream to a WAF or dedicated API gateway layer outside litellm until the patch is applied.

Sources: NVD VulnDB OpenSSF ATLAS

What is the risk?

CVSS 6.3 understates operational risk in enterprise deployments. Attack complexity is low, privileges required are low, and no user interaction is needed — an authenticated API user can exploit this immediately. The public exploit on GitHub (gist YLChen-007) means this is accessible to low-sophistication attackers. The affected component is specifically an enterprise security control: organizations that purchased or deployed the enterprise edition of litellm to enforce keyword-based content policies will have a false sense of protection. The 79/100 package risk score and 32 prior CVEs in this package strongly suggest inadequate security practices in the upstream codebase. No active exploitation confirmed (not in CISA KEV), but the exploit's public availability and low barrier make near-term abuse likely.

How does the attack unfold?

API Access

Attacker authenticates to the litellm enterprise deployment with low-privilege credentials (developer, service account, or compromised user) and targets the Completions Interface endpoint.

AML.T0040

Authorization Bypass

Attacker manipulates the prompt argument in the Completions request to trigger flawed logic in `async_pre_call_hook` within `enterprise/enterprise_hooks/banned_keywords.py`, causing the authorization check to return without blocking the request.

AML.T0049

Defense Evasion

The banned keywords enterprise security control silently fails — the request proceeds as if compliant, with no alert or log entry indicating a policy violation was attempted.

AML.T0107

Policy Violation Impact

Prohibited prompt content (PII, proprietary data, adversarial payloads, regulated terms) is forwarded unfiltered to the downstream LLM provider (OpenAI, Anthropic, Azure, etc.), defeating governance and compliance controls.

AML.T0024

API Access

Attacker authenticates to the litellm enterprise deployment with low-privilege credentials (developer, service account, or compromised user) and targets the Completions Interface endpoint.

AML.T0040

Authorization Bypass

Attacker manipulates the prompt argument in the Completions request to trigger flawed logic in `async_pre_call_hook` within `enterprise/enterprise_hooks/banned_keywords.py`, causing the authorization check to return without blocking the request.

AML.T0049

Defense Evasion

The banned keywords enterprise security control silently fails — the request proceeds as if compliant, with no alert or log entry indicating a policy violation was attempted.

AML.T0107

Policy Violation Impact

Prohibited prompt content (PII, proprietary data, adversarial payloads, regulated terms) is forwarded unfiltered to the downstream LLM provider (OpenAI, Anthropic, Azure, etc.), defeating governance and compliance controls.

AML.T0024

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	—	No patch
51.0K OpenSSF 6.1 6 dependents Pushed today 36% patched ~41d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

6.3 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C Low

I Low

A Low

What should I do?

5 steps

PATCH

Upgrade litellm above 1.82.5 as soon as a patched release is available — monitor the official litellm releases and VulnDB entry https://vuldb.com/vuln/372559 for patch confirmation.
INTERIM CONTROL

If patching is blocked, disable the enterprise banned keywords hook and replace with content filtering at a layer outside litellm: WAF rules, a dedicated content policy service, or API gateway middleware that validates prompt content before routing to litellm.
DETECTION

Query application logs for API calls to the Completions endpoint containing keyword patterns that should have been blocked — anomalous content in prompt fields post-exploitation will be visible in upstream LLM provider logs even when litellm failed to block them.
AUDIT

Review all prompts sent to downstream LLM providers over the past 30 days for policy violations that may indicate prior exploitation.
NETWORK CONTROL

Restrict Completions Interface access to known service accounts and internal networks only — PR:L means any authenticated user is a potential attacker, so reducing the authenticated population reduces blast radius.

How is it classified?

Auth Bypass Prompt Injection Inference API Framework AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0051.000 - Direct AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

6.1.2 - AI Risk Assessment 8.4 - AI System Operation

NIST AI RMF

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

OWASP LLM Top 10

LLM01:2025 - Prompt Injection

Frequently Asked Questions

What is CVE-2026-12797?

A low-privileged remote attacker can manipulate the prompt argument passed to litellm's enterprise banned keywords hook — the `async_pre_call_hook` function in `enterprise/enterprise_hooks/banned_keywords.py` — to bypass content authorization checks entirely in the Completions Interface. For organizations using litellm as an LLM API gateway with banned keyword lists as a compliance or data-loss control (e.g., blocking submission of PII, proprietary terms, or prohibited topics to external LLM providers), this control is rendered ineffective without any indication to defenders. A public exploit is already live on GitHub, dropping the exploitation bar to near-zero for any authenticated user, and litellm's track record of 32 CVEs in the same package with an OpenSSF scorecard of only 6.1/10 signals systemic security debt. Upgrade past 1.82.5 immediately; if patching is blocked, move keyword filtering enforcement upstream to a WAF or dedicated API gateway layer outside litellm until the patch is applied.

Is CVE-2026-12797 actively exploited?

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

How to fix CVE-2026-12797?

1. PATCH: Upgrade litellm above 1.82.5 as soon as a patched release is available — monitor the official litellm releases and VulnDB entry https://vuldb.com/vuln/372559 for patch confirmation. 2. INTERIM CONTROL: If patching is blocked, disable the enterprise banned keywords hook and replace with content filtering at a layer outside litellm: WAF rules, a dedicated content policy service, or API gateway middleware that validates prompt content before routing to litellm. 3. DETECTION: Query application logs for API calls to the Completions endpoint containing keyword patterns that should have been blocked — anomalous content in prompt fields post-exploitation will be visible in upstream LLM provider logs even when litellm failed to block them. 4. AUDIT: Review all prompts sent to downstream LLM providers over the past 30 days for policy violations that may indicate prior exploitation. 5. NETWORK CONTROL: Restrict Completions Interface access to known service accounts and internal networks only — PR:L means any authenticated user is a potential attacker, so reducing the authenticated population reduces blast radius.

What systems are affected by CVE-2026-12797?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways, enterprise LLM proxies, model serving, AI governance and compliance pipelines, multi-tenant LLM platforms.

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

CVE-2026-12797 has a CVSS v3.1 base score of 6.3 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

LLM API gatewaysenterprise LLM proxiesmodel servingAI governance and compliance pipelinesmulti-tenant LLM platforms

MITRE ATLAS Techniques

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0051.000 Direct

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: 6.1.2, 8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM01:2025

What are the technical details?

Original Advisory

A security flaw has been discovered in BerriAI litellm up to 1.82.5. Affected is the function async_pre_call_hook of the file enterprise/enterprise_hooks/banned_keywords.py of the component Completions Interface. The manipulation of the argument prompt results in incorrect authorization. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure.

Exploitation Scenario

An adversary with legitimate low-privilege API credentials to a corporate litellm enterprise gateway — such as a developer, contractor, or compromised service account — crafts a request to the Completions Interface where the prompt argument is manipulated in a specific way that triggers the flawed authorization logic in `async_pre_call_hook`. The banned keywords check evaluates incorrectly and returns without blocking the request. The adversary is now free to submit prompts containing content that should be prohibited: proprietary source code, customer PII, regulated data, or jailbreak payloads intended to manipulate the downstream LLM. In an enterprise context where litellm acts as the single enforcement point between internal users and external LLM APIs (OpenAI, Anthropic, Azure), this bypass nullifies the entire content governance layer. The publicly available exploit script on GitHub (https://gist.github.com/YLChen-007/078179224f07cc4e39e4f141a18c817a) means an attacker needs only the gist and valid API credentials to execute the attack.

Weaknesses (CWE)

CWE-285 Improper Authorization Primary CWE-863 Incorrect Authorization Primary CWE-285 Improper Authorization CWE-863 Incorrect Authorization

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

Source: MITRE CWE corpus.