Summary
A tenant-isolation authorization bypass in LiteLLM's semantic cache can allow an authenticated user with a valid virtual key to retrieve cached responses belonging to another tenant. On affected routes, semantically similar requests may expose sensitive data or return cached tool-call content that an agentic client could execute under a victim's credentials.
Affected context
The vulnerability occurs in deployments that use LiteLLM's semantic caching for multi-tenant traffic on affected routes, including response and Bedrock integrations. It becomes risky when cache entries are shared across principals and the metadata key used to determine tenant scope does not match the key used when storing or retrieving cache metadata.
Exploit preconditions
- Attack surface: Semantic cache handling on affected API routes, such as
/v1/responsesand/bedrock/* - Required access: An authenticated account or client possessing a valid virtual key
- Trigger point: Submission of a prompt that is semantically similar to a cached request from another tenant
- Why exploitation is possible: Inconsistent tenant metadata naming can cause cache lookups to omit or misapply tenant boundaries, allowing a response associated with a different principal to be returned
- Additional risk condition: A downstream agentic frontend may automatically process returned
function_callortool_callscontent
Why this happens
The underlying bug is an authorization-boundary mismatch in semantic cache metadata. The function that determines a tenant scope uses a different metadata key from the function that stores or retrieves that scope, so cache isolation can fail even though tenant-aware logic appears to be present.
This maps to CWE-863: Incorrect Authorization, because a request can receive data or behavior that should be restricted to another tenant. The insecure pattern is relying on inconsistent identity or scope attributes when enforcing authorization across shared caches.
Potential impact
- Cached responses may disclose other tenants' personally identifiable information
- Financial records, prompts, source code, or other sensitive content could be exposed
- Attackers could learn information across tenant boundaries
- Cached function-call or tool-call payloads could cause unintended actions in downstream agentic systems
- Victim-authorized tools or integrations could be invoked with attacker-influenced inputs
- Trust between tenants and the service could be degraded
General mitigation guidance
Mitigation typically focuses on making tenant authorization explicit, consistent, and fail-closed throughout cache operations.
Common defensive patterns include:
- Deriving cache scope from a canonical, authenticated tenant or principal identity
- Using one shared, strongly typed metadata definition for cache writes, reads, and scope checks
- Including tenant and authorization context in cache keys rather than relying on loosely named metadata fields
- Preventing cache responses from crossing tenant or principal boundaries
- Treating cached tool-call content as untrusted and requiring explicit authorization before execution
- Applying least-privilege permissions to tools, credentials, and downstream integrations
- Disabling shared semantic caching for routes or response types that cannot provide reliable isolation
- Preserving tenant-boundary tests for cache hits, misses, invalidation, and semantically similar requests
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis and code review checks for inconsistent metadata-key names or duplicated scope derivation logic
- Tests that populate a cache under one tenant and verify that equivalent requests from another tenant cannot receive the entry
- Dynamic testing with semantically similar prompts across separate identities and virtual keys
- Monitoring cache-hit responses for tenant identifiers that differ from the authenticated request context
- Policy enforcement requiring canonical identity fields in shared-cache keys and authorization decisions
- Review of agentic clients to ensure returned tool-call content is not executed without independent authorization
Automated security testing and code-review tools can help identify cross-tenant cache access patterns.
