The paper
HijackKV paper information
Accepted at USENIX Security 2026, Paper · Code and artifacts We thank Dr. Junchen Jiang, CEO and Co-Founder of Tensormesh, for valuable discussions and feedback.
01 · The reuse bet
Same text does not mean same state
Non-prefix KV-cache reuse makes a useful bet: if the same text chunk appears in two prompts, part of the chunk’s earlier computation can be reused.
CacheBlend-style reuse makes this practical by retrieving a chunk’s cached KV state and selectively recomputing tokens under the new context.
HijackKV, accepted at USENIX Security 2026, turns non-prefix reuse from a matching problem into a trust problem. The state depends not only on the matched chunk, but also on the context that preceded it.
02 · Root cause
The missing binding
With strict prefix caching, the cached token sequence is tied to the preceding tokens in the same prefix. Position-independent reuse deliberately relaxes that restriction so the same document, code file, or agent skill can be reused at different prompt positions.
The optimization assumes that the old and new contexts are merely different. HijackKV considers an adversarial old context. A malicious prefix can change the KV representation of an otherwise unchanged chunk; matching the chunk later can retrieve a state influenced by that prefix.
Under the paper’s threat model, the cache key identifies the matched token sequence—but not who produced the state, under which preceding context, or whether that context was trusted.
03 · Threat model
The attack
HijackKV assumes a multi-tenant service with a shared position-independent KV-cache pool. The attacker is an unprivileged user: they cannot directly edit cache tensors, change the model, or modify the victim’s prompt.
The attacker chooses a benign chunk likely to be reused and optimizes a prefix that conditions the chunk’s KV state toward a target output. The optimized prefix and chunk are then submitted together to seed the shared cache.
A victim later retrieves the same benign text chunk, causing the system to reuse its cached KV state. The malicious prefix was used only to create the cache entry and is then discarded—it never appears in the victim’s prompt and is not itself reused. Its influence, however, persists in the retrieved state.
04 · Findings
What the findings show
HijackKV reports targeted attack success rate (T-ASR), a strict metric that counts an attack as successful when the attacked response matches the attacker-designated target answer and differs from the benign response.
Invisible at the text boundary
The victim prompt can remain entirely benign, leaving a victim-side scanner with no malicious token sequence to remove.
Broad coverage
The study spans general and medical QA, code generation, models from 1B to 70B, and multiple reuse settings.
Effective on code
On HumanEval, average T-ASR was 95.5% across decoding temperatures.
Persistent and transferable
The effect survived unrelated intervening context and transferred across model families without target-model gradients.
Recomputation alone is costly
At 50% recomputation, average T-ASR was still 39%. A stronger hybrid strategy reduced it to 11.5% at 80% recomputation, but incurred 3.53× recomputation cost.
05 · Deployment reality
What they mean, and what they do not
HijackKV evaluates CacheBlend-style position-independent KV reuse under online, cross-user position-independent cache reuse in which cached chunks may inherit attacker-controlled preceding context.
Practical exploitability depends on deployment conditions that the study does not observe:
- Whether untrusted requests can publish entries to a shared cache pool.
- Whether a victim matches a malicious entry before it is evicted or overwritten through trusted pre-warming.
- How cache admission, replacement, quotas, and namespaces are configured.
- How accurately an attacker can predict shared content and transfer an optimized prefix to the deployed model.
Strict prefix caching, cache isolation by user, and RAG pipelines that independently precompute trusted document chunks before serving eliminate this attack path.
06 · Design response
A safer reuse boundary
The strongest design principle is to prevent untrusted state from silently becoming shared state.
Isolate publication
Do not let untrusted requests populate caches used by other users.
Track provenance
Reuse state only when its source is compatible with the current request.
Verify before reuse
Compare selected cached states with a small fresh computation and reject unsafe deviation.
Rate limits, quarantine windows, cache-lineage logs, anomaly detection, and rapid invalidation can narrow the attack window, but they do not replace isolation and verification.
07 · Further reading