Advisory · CVE-2026-89032
LiteLLM semantic cache leaks one tenant's responses to another
BerriAI LiteLLM before 1.101.0-rc.1 has a tenant isolation bypass in the semantic cache layer that lets an authenticated user retrieve other tenants' cached responses, including PII, financial data, and source code.
- Vendor
- BerriAI
- Product
- LiteLLM
- Identifier / CWE
- CVE-2026-89032
CWE-863 - Action timing
- Immediate
Explain it like I’m five
LiteLLM keeps a shared pantry of answers so it can serve them fast. It labels each shelf by tenant, but two labels use different handwriting, so a tenant can ask for their own snack and get handed a neighbor's lunchbox with their private notes inside.
- 01Valid key
An attacker holds a valid LiteLLM virtual key with access to an affected route such as /v1/responses or /bedrock/*.
- 02Similar prompt
The attacker submits a prompt semantically similar to one a different tenant previously asked.
- 03Scope mismatch
A metadata key mismatch between the semantic cache tenant scope functions returns another tenant's cached response.
- 04Data disclosure
The attacker receives the other tenant's cached response, which may contain PII, financial data, source code, or tool-call payloads usable under victim credentials.
What happened
BerriAI LiteLLM before 1.101.0-rc.1 contains a tenant isolation bypass in its semantic cache layer, disclosed on September 25, 2026. A metadata key mismatch between the cache tenant scope functions means cached responses are not reliably attributed to the tenant that produced them. An authenticated user with a valid virtual key can submit semantically similar prompts on affected routes such as /v1/responses and /bedrock/* and receive cached responses belonging to other tenants. Those responses can contain personally identifiable information, financial data, or source code, and returned function_call or tool_calls payloads can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials. It is rated high at CVSS 8.7.
LiteLLM is the shared front door many teams put in front of their LLM providers. A cache that mixes up whose data is whose turns a performance feature into a cross-customer disclosure.
What to do
- Inventory LiteLLM deployments and check the running version.
- Upgrade to LiteLLM 1.101.0-rc.1 or later, which contains the fix.
- If immediate upgrade is not possible, disable the semantic cache layer until the upgrade lands.
- Review semantic cache and gateway logs for cross-tenant cache hits, unusual prompt patterns, or repeated similar-prompt probing.
- Assume cached responses may have crossed tenant boundaries; notify affected tenants if exposure cannot be excluded.
- Rotate any credentials, API keys, or tokens that passed through cached responses.
Management note
This is a data-governance incident wearing a vulnerability costume. The exploit requires a valid key, so the exposure is bounded to existing tenants, but those are exactly the parties with contractual confidentiality expectations. Upgrade first, then answer the awkward question: whose cached responses sat in the shared cache, and who else could have asked for them.