What it is
Cache lookup keys come from request content: token sequences, prefix chains, block hashes. They fail in three different ways, and the fixes do not substitute for each other. Width fixes (c). Only binding authenticated identity fixes (a).
Variants and records
(a) Namespace omitted
The cache key is built from what was asked, not from who asked. Two customers sending the same prompt get the same cache entry, so one can be served what the other stored.
No public record yet. It follows from how the key is built.
(b) Version context omitted
The key leaves out which model version, tokenizer or adapter made the entry. Entries get reused across setups that should be separate, which matters when those setups belong to different customers.
No public record yet. It follows from how the key is built.
(c) Weak identifier
The ID used to look up an entry is too short, so an attacker can craft two different inputs with the same ID and have one served in place of the other.
LMCache used a 16-bit hash for multimodal entries. CVE-2026-10813 (GHSA-3hh9-752g-5g22), published 2026-06-04.
One rule. Derive storage identity from a namespace bound at the gateway, and keep it in the key that reaches storage.
Check your stack
Tests
Each test has a positive control: a condition under which it must fail. A test that cannot fail proves nothing. These are procedures. Hedgerow has not run them.
Same prompt, two tenants
- Do
- Send the same prompt from two authenticated tenants through every cache tier.
- Pass
- Tenant B misses on every tier.
- Must fail when
- Isolation is switched off. If B still misses, the test is blind.
Unsupported isolation input
- Do
- Send a request with an isolation field the cache layer does not implement.
- Pass
- The request is refused, not served.
- Must fail when
- A sibling cache layer known to ignore the field is used.
Key field audit
- Do
- Dump the key inputs at the storage layer, not the in-memory index.
- Pass
- A namespace from authenticated identity is present.
- Must fail when
- A tier that drops the namespace is configured.
Mapping to AISVS, ATLAS and CWE
| Framework | Mapping |
|---|---|
| OWASP AISVS 1.01 | Closest: 5.3.1 (shared serving must not let one tenant influence or observe another), 5.2.7 (classification labels propagate to prompt caches) and 3.3.3 (parallel model versions use isolated runtime state). None addresses the content of the cache key. |
| MITRE ATLAS 5.6.0 | Partial: AML.T0057 LLM Data Leakage, which includes information from other users. It describes adversary-crafted prompts, so (a) and (b), which need no attacker, do not fit exactly. |
| CWE | (c): CWE-327, as assigned in the advisory. (a): CWE-639 Authorization Bypass Through User-Controlled Key (Hedgerow proposal). |
Controls
- Derive storage identity from an authorization namespace bound at the gateway, not from a caller-supplied value alone.
- A caller-chosen salt is a mechanism, not a tenant boundary: a caller can choose another caller's value. Bind it to authenticated identity at ingress.
- Keep the namespace in the key that reaches storage, not only in an in-memory index.
What this page does not claim
- The tests have not been run by Hedgerow.
- Standards mappings reflect the versions named and may change as they do.
- A cited record shows the mechanism occurred in at least one implementation. It does not say any given system is affected.