CVE-2026-12797: BerriAI litellm Banned Keywords Bypass Vulnerability

Technical summary

The vulnerability resides in the async_pre_call_hook function within enterprise/enterprise_hooks/banned_keywords.py. This hook is responsible for enforcing keyword-based authorization policies before processing completion requests. By submitting specially crafted prompt arguments, an authenticated attacker can bypass the authorization logic that should block requests containing banned keywords. The flaw stems from improper validation or sanitization of prompt input before authorization checks are applied, allowing prompt manipulation to evade filtering mechanisms.

Business impact

Organizations relying on litellm's banned keyword enforcement for compliance, safety, or acceptable-use policy enforcement face a direct risk of policy bypass. Authenticated users could submit requests that should be blocked, potentially leading to generation of prohibited content, exposure of sensitive model capabilities to unauthorized use cases, or violation of internal governance policies. The scope is limited to authenticated users, reducing the overall blast radius but still representing a meaningful control circumvention.

Affected systems

BerriAI litellm versions up to and including 1.82.5 are affected. Any deployment using the enterprise keyword filtering feature in the Completions Interface is at risk if running a vulnerable version. Organizations should verify their current litellm version and assess whether they rely on the banned_keywords enterprise module for policy enforcement.

Exploitability

Exploitability is moderate. The attack requires valid authentication credentials (authenticated access to the LLM API), which limits opportunistic exploitation. However, once authenticated, the attack is straightforward—no complex timing, race conditions, or system-specific configuration is required. The existence of public exploit code lowers the technical barrier for any attacker with valid access. The attack vector is network-based with no user interaction required beyond submitting a malformed request.

Remediation

Upgrade BerriAI litellm to a patched version released after 1.82.5. Verify the exact version number in the vendor's security advisory. Until patching is feasible, consider implementing compensating controls: apply additional input validation and keyword filtering at the application layer above litellm, restrict API access to trusted internal services only, and monitor request logs for suspicious prompt patterns that attempt to obfuscate banned keywords.

Patch guidance

Review BerriAI's official security advisory and release notes for the recommended patched version. Apply the update to all systems running litellm, including development, staging, and production environments where the enterprise keyword filtering module is in use. Test patched deployments to confirm that banned keyword enforcement functions correctly and that legitimate traffic is not blocked. Document the patch application timeline and verify the fix by attempting to trigger the vulnerability with test prompts.

Detection guidance

Monitor litellm API logs for prompts that contain obfuscated or manipulated versions of known banned keywords. Look for patterns where authorized content filtering was bypassed or where requests containing policy-restricted terms were processed successfully. Implement application-level logging of all prompt inputs and authorization decisions. Hunt for signs of prompt injection or encoding techniques (Unicode variations, whitespace tricks, case mutations) that might indicate exploitation attempts. Compare request patterns before and after the vulnerability disclosure date to identify potential compromise.

Why prioritize this

Although the CVSS score is 6.3 (Medium), this vulnerability warrants prompt remediation because it directly undermines a critical security control—content filtering. The combination of public exploit code, ease of exploitation for authenticated users, and the fact that this breaks a trust boundary (policy enforcement mechanisms) elevates practical risk. Any organization relying on banned keywords for compliance or safety policies should prioritize patching to restore the integrity of that control layer.

Risk score, explained

The CVSS 3.1 score of 6.3 (Medium, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) reflects network-accessible attack vector, low complexity, requirement for low-privilege authentication, no user interaction, and limited impact on confidentiality, integrity, and availability. The score appropriately captures that exploitation requires credentials and does not grant full system compromise. However, the practical severity is amplified by the control-bypassing nature of the flaw and the existence of public exploits.

Frequently asked questions