CVE-2026-12797: BerriAI LiteLLM security bypass in BannedKeywords and AzureContentSafety hooks

CVE-2026-12797 · Severity: medium · CVSS 6.3 · Published 2026-06-21

BerriAI litellm is a popular proxy and abstraction layer for large language models used by enterprises to manage API calls and enforce security policies. The product includes content filtering and safety guardrails (BannedKeywords and AzureContentSafety) intended to block harmful or policy-violating input before it reaches the underlying LLM. Due to a coding error where the security hooks check for the wrong routing type, these protections are completely disabled for all HTTP API requests, allowing attackers to bypass content filters silently. Organizations relying on these guardrails believe they have active protection when in fact no filtering occurs.

Technologies: Berriai LiteLLM, litellm (PyPI). Vendors: Berriai, PyPI.

Quick answers

Is CVE-2026-12797 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-12797 being exploited in the wild.
How severe is CVE-2026-12797?
Medium severity, with a CVSS score of 6.3, published 21 June 2026.
Which products and versions are affected?
Berriai LiteLLM <= 1.82.5; litellm (PyPI) ECOSYSTEM:introduced=0,last_affected=1.82.5.
Is there a fix for CVE-2026-12797?
No fixed version is recorded yet. Check the vendor's advisory in the references below. If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is CVE-2026-12797 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-12797?
Check whether you run Berriai LiteLLM or litellm (PyPI) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The vulnerability is an improper authorization bypass (CWE-285) caused by an incorrect call_type comparison in two security hooks. When HTTP requests arrive at /v1/chat/completions, the proxy routes them asynchronously and sets call_type to "acompletion"; however, the BannedKeywords.async_pre_call_hook() and AzureContentSafety.async_pre_call_hook() functions only check for call_type == "completion", causing the condition to always evaluate false and the security check body to be skipped entirely. This allows requests containing banned keywords or unsafe content to bypass the guardrails. Other hooks in the codebase (presidio.py, guardrails_ai.py) were previously patched to check for both "completion" and "acompletion", indicating this was a known issue that was incompletely fixed. The vulnerability requires the attacker to have valid API credentials (low privilege) and can be exploited remotely over the network with no user interaction required. No patch has been released as of the advisory date.

Affected products

  • BerriAI litellm <= 1.82.5

Identifiers

  • CVE-2026-12797
  • GHSA-p897-vf7j-f5h8
  • PYSEC-2026-4074

Timeline

  • 2026-06-21: disclosed: Published to GitHub Advisory Database
  • 2026-09-14: advisory: GitHub reviewed and confirmed

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.