CVE-2026-89032: 
Chainguard vulnerability analysis and mitigation

CVE-2026-89032 is a tenant isolation bypass vulnerability in BerriAI LiteLLM's semantic cache layer that allows authenticated users to read other tenants' cached responses. The flaw stems from a metadata key mismatch between the _get_semantic_cache_tenant_scope() and _get_metadata_variable_name() functions, causing the cache to serve responses across tenant boundaries. All versions of LiteLLM before 1.101.0-rc.1 are affected. It was published on September 25, 2026, with a CVSS v3.1 score of 7.7 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is classified under CWE-524 (Use of Cache Containing Sensitive Information) and CWE-863 (Incorrect Authorization). The semantic cache layer in LiteLLM uses a tenant scope key built by _get_semantic_cache_tenant_scope(), but a mismatch with the metadata variable name lookup means the end-user identity is not incorporated into the cache bucket key by default. As a result, any authenticated user holding a valid virtual key can submit semantically similar prompts to routes such as /v1/responses, /v1/chat/completions, /v1/messages, and /bedrock/*, and the cache will return responses generated for a different tenant. The fix introduced an opt-in cache_params.semantic_cache_scope: end_user parameter that appends the authenticated end-user ID to the cache bucket key, reading identity from both metadata and litellm_metadata containers to cover all affected routes (GitHub PR #39590, GitHub Commit).

Successful exploitation allows an authenticated attacker to read cached responses belonging to other tenants, potentially exposing personally identifiable information (PII), financial data, or proprietary source code. Beyond data disclosure, attackers can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials by returning cached function_call or tool_calls payloads to a different principal, enabling unauthorized actions within connected automated agent workflows. The CVSS v4.0 scoring reflects high confidentiality and integrity impact on both the vulnerable and subsequent systems, with no availability impact (Github Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.272% (18th percentile), indicating a low near-term exploitation probability. Exploitation requires a valid virtual key (low privileges) and some degree of user interaction (passive), and attack complexity is rated High due to the need to craft semantically similar prompts that match cached entries.

1. Obtain a valid virtual key: Register or obtain a legitimate virtual API key for the target LiteLLM proxy instance. Any authenticated low-privilege user qualifies.
2. Identify target routes: Determine which semantic-cache-enabled routes are active on the proxy, such as /v1/chat/completions, /v1/responses, /v1/messages, or /bedrock/*.
3. Probe the cache: Submit prompts to the target routes. Because the default semantic_cache_scope is key (not end_user), all users sharing a virtual key or team/org share the same cache bucket.
4. Craft semantically similar prompts: Using the same or semantically equivalent prompts (e.g., paraphrases above the configured similarity_threshold, typically 0.8), submit requests with a different x-litellm-customer-id header than the victim tenant.
5. Retrieve cross-tenant cached responses: The cache returns the victim tenant's previously cached response — including full LLM output, tool call results, or function_call/tool_calls payloads — to the attacker.
6. Abuse tool call payloads (optional): If the cached response contains function_call or tool_calls entries, an agentic front-end receiving this response may auto-execute those tool calls under the victim's credentials, enabling unauthorized actions (GitHub PR #39590, Github Advisory).

• Network: Repeated HTTP POST requests to /v1/chat/completions, /v1/responses, /v1/messages, or /bedrock/* from the same source IP using different x-litellm-customer-id headers with semantically similar prompt bodies; cache hit responses (x-litellm-cache: hit) returned to a different customer ID than the one that originally populated the cache.
• Logs: LiteLLM proxy access logs showing cache hits (cache_hit: true) for requests from a different user_api_key_end_user_id than the originating request; multiple distinct end-user IDs receiving identical response IDs (e.g., same chatcmpl-* or created_at timestamp) in a short time window.
• Application Behavior: Agentic front-ends executing unexpected tool calls or function calls not initiated by the authenticated user; downstream API calls made under victim credentials that do not correspond to any action initiated by that user.

Upgrade BerriAI LiteLLM to version 1.101.0-rc.1 or later, which introduces the semantic_cache_scope parameter to enforce per-end-user cache isolation (GitHub Release). After upgrading, administrators should explicitly set semantic_cache_scope: end_user under cache_params in the proxy configuration to enable per-end-user isolation; the default remains key (shared) for backward compatibility. A backport to the stable 1.100.x branch was also released as version 1.100.5 (GitHub PR #39590). As an interim workaround, disabling the semantic cache entirely eliminates the attack surface until patching is possible. Additionally, review access logs for suspicious cross-tenant cache hit patterns and audit any agentic workflows for unauthorized tool call executions.

The vulnerability was reported via Red Hat Bugzilla (Bug #2541509) and assigned high severity by Red Hat's Product Security team, with 19 users CC'd on the tracking issue (Red Hat Bugzilla). The fix was noted in the NixOS/nixpkgs security tracker (issue #567123), indicating downstream Linux distribution awareness. Social media activity was limited, with brief mentions on Bluesky and Mastodon shortly after disclosure, but no significant researcher commentary or media coverage has been identified.