Sharing a cache can change someone else's answer: a walkthrough of the HijackKV paper

HijackKV, posted to arXiv on July 22, 2026 (arXiv 2607.19957), shows that in LLM serving systems using position-independent KV cache reuse, a cache planted by an attacker can change another user's answer. The authors report an average 94% success rate in a single attempt, and the attack survives realistic constraints including cache hit rates as low as 10% and recomputation of 50% of the cache. What distinguishes it is that no attacker-controlled text appears anywhere in the victim's input. ASAP works from the arXiv paper directly to lay out how the attack works, what the numbers say, and which defenses hold.

The opening that position-independent reuse creates

KV caching is standard practice for cutting LLM inference latency. Traditional prefix-based reuse requires exact token and position matches, which keeps hit rates low across inference requests. Recent system optimizations introduced position-independent KV reuse to get past that ceiling, allowing a cache to be reused whenever identical text chunks appear regardless of their position in the sequence.

The risk HijackKV identifies follows directly from that premise. KV caches are retrieved by token match, but what they encode is the context in which they were originally computed, so the KV attached to a benign-looking token chunk may encode an attacker-controlled prefix. When that contaminated KV is later reused in a victim query, it silently hijacks the model's behavior, and the victim's input contains none of the attacker's text.

The attack framework operates on exactly that gap. HijackKV optimizes an attacker-controlled prefix so that the KV computed for a subsequent common benign text encodes the attacker's goal while the text itself stays unchanged, which keeps future cache hits working normally.

Success rates measured on Llama, Qwen, and Mistral

The evaluation spans three model families: Llama-3.1-8B, 3.2-1B, 3.2-3B, and 3.3-70B; Qwen3-4B, 3-8B, and 3-14B; and Mistral variants. Four question-answering benchmarks supply the data, HotpotQA, SQuAD, MedQA, and PubMedQA, with 200 sampled instances each.

The comparison across recomputation strategies carries the result. Targeted attack success ran between 85% and 100% with no recomputation, 75% to 93% under EPIC, which recomputes the initial tokens of each cached chunk, and 80% to 89% under CacheBlend, which recomputes selectively based on attention deviation. Averaged across datasets on Llama-3.1-8B, targeted success is 89%.

Attacker goals fall into three categories: flipping binary questions to the opposite answer, steering multiple-choice questions to an incorrect option, and producing semantically related but wrong entities on open-ended questions, such as answering "Hawaii" instead of "Paris" for a capital-city question.

Black-box transfer was measured too. Prefixes optimized on a Llama-3.1-8B proxy reached 87% untargeted and 38% targeted success on Qwen3-8B, 79% and 37% on Llama-3.3-70B, and 90% and 44% on Llama-3.2-3B. Targeted success collapsed to 9% on Qwen3-4B, and the authors conclude that prefixes optimized on larger proxy models work against similarly capable targets but not against significantly smaller ones.

Why 94% and 89% are not the same number

Reading the abstract's 94% and the table's 89% as one figure gets the threat wrong. The paper reports success along two axes: targeted attack success (T-ASR) requires eliciting the specific wrong answer the attacker chose, while untargeted success (U-ASR) only requires the output to deviate from the correct answer. The transfer table lists both side by side, and on Qwen3-8B they diverge by more than a factor of two, 87% against 38%.

That distinction matters operationally because it changes the threat model. If the goal is degrading service quality, untargeted success is the relevant metric and it stays high across most settings. If the goal is precise manipulation, such as steering a recommendation toward one brand or nudging a diagnosis, targeted success governs, and it falls sharply once the target model differs from the proxy. In its current form the attack is robust at broad disruption and conditional at precise steering.

What holds as a defense and what does not

The practical conclusion is that most existing defenses do nothing here. Text-level defenses are irrelevant by construction, since the attack manipulates internal representations without injecting adversarial text into the input. Quantization and KV cache compression methods also failed to prevent the attack.

Recomputation volume is the one axis with measured effect. Raising the recomputation ratio from 10% to 50% drops targeted success from 89% to 39%, and cutting the cache ratio from 50% to 10% brings it from 100% down to 81%. The problem is that both moves undo the exact reason position-independent reuse was adopted, since more recomputation and less caching push latency and cost back up, and the 10% to 15% recomputation ratios common in deployment are not sufficient.

The direction the authors propose is authenticating cached KV states so that unauthorized reuse cannot occur. The paper does not quantify what that authentication costs in throughput.

How to read this result

Scope is the first thing to establish, because HijackKV applies only to systems using position-independent KV reuse and the authors state that prefix-only caches remain secure. Two questions determine exposure: which reuse policy a serving stack implements, and whether its cache pool is shared across tenants.

The general lesson is that a performance optimization moved a security boundary. Cache sharing was treated as a pure efficiency decision about latency and cost, and it rarely entered threat modeling at all. HijackKV demonstrates that once the shared object is computed internal state rather than text, that decision becomes a trust-boundary decision. The same question applies to every multi-tenant optimization that buys performance by sharing something.

The realism of the attack's preconditions deserves equal weight. The paper names three: the attacker must be able to inject inputs into the shared cache pool, must be able to probe whether specific chunks are cached, and depends on eviction policies retaining the cache long enough. The first condition is easy to satisfy on a public API service and much harder in a private internal deployment. The authors' note that different eviction strategies may reduce persistence also implies that short cache lifetimes provide incidental mitigation.

Open questions

The four datasets used in HijackKV, HotpotQA, SQuAD, MedQA, and PubMedQA, are all question-answering benchmarks, so the attack is measured entirely on QA-format tasks. Given that, whether the same success rates hold for tasks where output becomes action, such as code generation or agentic tool calls, has not been measured. By severity the latter is the larger concern, and it sits outside this paper's scope.

Reproduction on live serving systems also remains open. The authors state that the work was conducted locally in a simulator using a surrogate model, thereby avoiding any impact on the remote server-side model or cache pool. That is the right ethical choice, but it means the paper cannot answer how success rates shift under real eviction policies and traffic patterns. The paper includes a stakeholder analysis separating implementers of position-independent KV reuse, service providers running multi-tenant architectures, and end users, and the source code was released alongside it.

Source: ASAP walkthrough based on arXiv 2607.19957, "HijackKV: New Threat in Position-Independent KV Cache Reuse" (Yichi Zhang, Zhiqi Wang, Huan Zhang, Yuchen Yang, v1 July 22, 2026, v2 July 31, 2026).