Semantic Cache Poisoning: How a Shared LLM Response Cache Becomes an Agent Attack Surface

Semantic cache poisoning is an attack against the response cache that many LLM and agent deployments run in front of inference: an attacker with ordinary query access writes one crafted ⟨query, response⟩ pair into a shared, embedding-matched cache, and any later user whose wording lands within the cache's similarity threshold receives the attacker's chosen answer, with the underlying LLM never invoked at all. NDSS 2026 research demonstrated this against GPTCache, the largest open-source semantic-caching implementation, and its integrations into AWS Bedrock, Azure, and Alibaba Higress, with attack success rates from 81% to 89% across text-to-text and text-to-image use cases. This entry covers what the research establishes, why the cache's own value proposition (reuse across users, not just within one) is the precondition that turns a local optimization into a shared-state security boundary, and detection and containment that does not require disabling caching.

What it is

Semantic caching stores previously served ⟨query, response⟩ pairs and, before invoking the LLM, checks whether an incoming query is close enough in embedding space to a stored one to reuse its answer. This is distinct from exact-match caching: a new query does not need to be identical to a cached one, only similar enough to clear a similarity threshold (0.8 by default in GPTCache), evaluated in two phases, a fast top-K embedding filter followed by a finer text-similarity model such as SBERT. Leading cloud providers, including Azure, AWS Bedrock, and Alibaba Higress, have integrated this pattern into their LLM serving infrastructure because it cuts inference cost and latency, and because its main value comes from reuse across different users asking similarly worded questions, not from one user repeating themselves. The defining cause of semantic cache poisoning is that this write path is rarely authenticated or validated beyond ordinary API access: any caller whose query and response get cached has, in effect, contributed to what every later, unrelated caller may be served. The defining consequence is that a downstream agent, chatbot, or pipeline treats a cache hit as equivalent to a fresh model output, when it may instead be content an attacker chose, planted once, and never needs to deliver again.

What it is not

RAG poisoning, where a corrupted document in a knowledge base or vector index is retrieved and the LLM still runs, reasoning over the poisoned passage alongside the rest of its context. Semantic cache poisoning skips that step entirely: on a cache hit, the stored response is returned directly and no retrieval or generation happens to dilute or catch the injected content.
KV-cache prompt leakage, the confidentiality attack NDSS 2025 research named PROMPTPEEK, which exploits a timing and serving-order side channel in the low-level, per-token attention cache shared across requests in frameworks like vLLM and SGLang to reconstruct another user's private prompt. That attack reads; it never writes. Semantic cache poisoning is a write-side integrity attack on a separate, higher-level ⟨query, response⟩ cache purpose-built to skip inference outright.
Classic web cache poisoning or DNS cache poisoning, decades-old infrastructure attacks against exact- or near-exact-key caches (a URL, a hostname) with established defenses like cache-key normalization and DNSSEC. Semantic caching matches by embedding similarity above a threshold, so one poisoned entry can be served to many differently worded queries an operator never explicitly cached for.
A claim that response caching is inherently unsafe or should be disabled. Caching remains necessary for cost and latency at serving scale; this entry covers what breaks when a cache's write path is not authenticated or monitored, not caching itself.
Reproducible exploit code or a step-by-step poisoning recipe tuned to a specific cloud deployment's default similarity threshold.

In scope

Cache poisoning attacks against embedding-matched semantic response caches sitting between users (or agents) and an LLM inference engine, including GPTCache and its documented derivatives across AWS Bedrock, Azure, and Alibaba Higress.
Adversarial query crafting that clears a deployment's similarity threshold while remaining distinguishable to a human reader from the query it is meant to match.
Techniques for surviving cache eviction (FIFO, LRU, or time-based expiration) and for tolerating interference from unrelated, benign queries, both of which a durable poisoning effect depends on.
Downstream consequences specific to agent and code-facing use cases: poisoned agent-action caches, code-generation caches returning injected logic, and SQL-translation caches returning data-leaking or data-modifying queries.
Defensive controls for the cache write path, similarity-threshold hardening, sampling-based response verification, and eviction-policy tuning for high-risk query classes.

Target state and trust boundary

The target state is the ⟨query, response⟩ pair stored in the semantic cache layer, and, downstream, whatever an agent or application does with a cache-hit response it did not distinguish from a freshly generated one. The trust boundary that fails is the assumption that any entry clearing the similarity threshold is a valid answer to the new query, an assumption that holds only if every prior write to that cache came from a legitimate, unmanipulated ⟨query, response⟩ cycle. Because the cache sits ahead of the LLM in the request path, a poisoned hit bypasses not just the model's own reasoning but any content filtering or grounding step that normally runs on a fresh generation.

Persistence

A poisoned entry does not need repeat delivery: once written, it serves every subsequent user whose query embeds similarly, not just the attacker's own session, which places this squarely in shared-system scope rather than single-session scope. How long it survives depends heavily on deployment configuration. GPTCache's default cache holds up to 1,000 entries under FIFO or LRU eviction, so a poisoned entry can persist until enough new traffic displaces it. Cloud integrations instead favor time-based expiration; Alibaba Higress documents a default cache expiration of 10,000 milliseconds. The practical range runs from a ten-second window to an indefinite one gated only by traffic volume, which is why the NDSS 2026 researchers treat "maintaining a persistent poisoning effect" as one of the attack's own core requirements, not a given.

What the research establishes

NDSS 2026 research by Guanlong Wu, Taojie Wang, Yao Zhang, Zheng Zhang, Jianyu Niu, Ye Wu, and Yinqian Zhang, "When Cache Poisoning Meets LLM Systems: Semantic Cache Poisoning and Its Countermeasures," is the first work to demonstrate this class of attack end to end. The authors formalize four attack requirements: generating an attacker-chosen response for a target query, crafting adversarial queries judged semantically similar by the cache's own embedding and similarity-evaluator models, overcoming interference from unrelated queries, and maintaining the poisoning effect against eviction. Evaluated against GPTCache and, under black-box conditions, against real deployments on AWS Bedrock, Azure, and Alibaba Higress, crafted adversarial queries reached an average similarity of 0.87 (black-box) to 0.94 (white-box) against target queries. Attack success rates reached 88% on GPTCache for text-to-text, 81% for text-to-image, and 82%, 89%, and 87% on AWS, Azure, and Alibaba respectively. The paper reports that consequences are application-dependent: poisoning an agent-related cache can trigger unintended or harmful API calls, poisoning a code-generation cache can return code carrying injected malicious logic or hidden vulnerabilities, and poisoning a SQL-translation cache can produce queries that leak sensitive data or modify a database. The authors also evaluated existing adversarial-prompting defenses, perplexity-based, paraphrase-based, and classifier-based detection, and found they yield low F1-scores against this attack; their own proposed defense reaches an F1-score of 0.87, which the authors describe as a meaningful improvement, not a complete mitigation (NDSS Symposium 2026, "When Cache Poisoning Meets LLM Systems: Semantic Cache Poisoning and Its Countermeasures").

The same research group's earlier NDSS 2025 paper, "I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving," is useful adjacent context: it introduced PROMPTPEEK, a side-channel attack reconstructing another user's private prompt from KV-cache sharing behavior in frameworks like vLLM and SGLang, reaching a 99% average success rate reversing prompt input on a Llama2-13B deployment, using as few as 60 requests when the prompt template was known. The authors disclosed the finding to SGLang, OpenAI, ByteDance, and Anthropic (NDSS Symposium 2025, "I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving"). It targets a different cache layer and a different goal (confidentiality, not integrity), but it establishes the same underlying pattern: shared inference-serving infrastructure, optimized for cost and latency across tenants, creates state that one tenant's crafted requests can manipulate to affect another's. GPTCache itself, the reference implementation both cache-poisoning evaluations and most cloud integrations build on, is documented as open source at github.com/zilliztech/GPTCache.

Detection: observable signs

A response served to a query with no corresponding LLM invocation or token-generation cost in inference logs, where the served content would not plausibly come from a fresh model call for that query.
Multiple distinct users receiving identical or near-identical responses to differently worded queries, where that shared response contains anomalous content: unexpected URLs, unrequested code paths, or off-topic instructions.
A sudden spike in cache-hit rate for a query cluster around a previously rare topic within a short window, consistent with an attacker seeding adversarial queries to overcome interference from benign traffic.
Embedding-similarity scores for cache hits clustering suspiciously close to the deployment's threshold rather than distributed naturally across the normal range.
A cached response that diverges from what the same query produces on a fresh, cache-bypassed LLM call when spot-checked.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

Control	Transition it interrupts	Applicability	Residual risk and verification
Authenticate and rate-limit the cache-write path per caller identity	An attacker with ordinary query access silently writing a crafted entry into a cache every later caller reads	Any deployment where a cache write is triggered implicitly by any user's query rather than by a privileged operator	Does not stop a legitimate but compromised account from poisoning; pair with anomaly monitoring on write volume per identity.
Harden the similarity threshold and similarity-evaluator model against adversarial queries	Adversarial queries crafted to sit just above the deployment's default similarity threshold	Any semantic cache using embedding plus threshold matching, including GPTCache and its cloud derivatives	The paper found perplexity-, paraphrase-, and classifier-based prompting defenses largely ineffective; its own proposed defense reached F1 0.87, not complete mitigation — retest per deployment before relying on it.
Sample cache hits against a fresh, cache-bypassed LLM call for high-value query classes	A poisoned entry continuing to serve corrupted content undetected after the initial write	Deployments that can absorb the added inference cost for sensitive categories (agent actions, code generation, data queries)	Sampling only catches poisoning with some probability; scope it to the highest-risk query classes rather than uniform coverage.
Shorten TTL or tighten eviction for agent-action, code-generation, and data-query cache entries	A poisoned entry maintaining a persistent effect long enough to reach many victims	Deployments able to trade some cost and latency savings for a smaller poisoning window on high-risk categories	Reduces but does not eliminate the poisoning window, and gives up part of the reason caching exists; does not fix the lack of write authentication.
Treat cache-served content ingested into an agent's context as untrusted, same as any other input	Hidden-instruction or malicious-logic content in a poisoned entry being executed without further validation	Any agent framework that consumes cached responses as if they were fresh model output	Requires the framework to expose whether a given response was cache-served, which most current integrations do not surface to the calling agent.

Prevention should authenticate cache writes and harden the similarity threshold against adversarial crafting; because the paper's own defense tops out at F1 0.87, prevention alone should not be treated as sufficient. Detection should watch for the cache-hit and cross-user response-uniformity signals above, and spot-check sensitive query classes against fresh, cache-bypassed calls. Containment should invalidate the affected cache entry across every deployment serving it and suspend caching for the affected query cluster pending review. Recovery should re-verify any downstream action an agent already took on a cache-served response before the poisoning was caught, since a cache hit produces no model-reasoning trace to audit after the fact.

Boundaries with similar concepts

This differs from RAG poisoning in what gets poisoned and what gets bypassed. RAG poisoning corrupts the knowledge corpus a retrieval step draws from, and the LLM still runs, reasoning over the poisoned passage alongside legitimate context that may dilute or contradict it. Semantic cache poisoning corrupts a stored answer directly, and on a cache hit the LLM is not invoked at all, so no reasoning step gets a chance to catch the injected content.

This also differs from compromised summaries and context compaction in mechanism, though both concern the Context state surface. Compaction risk concerns an agent's own session history being condensed in a way that preserves adversarial content while dropping valid constraints. Semantic cache poisoning concerns a serving-layer object shared across unrelated sessions and users, written once by an attacker with no special access beyond an ordinary query.

Mapping to standards and research

Source	Source-owned term or item	Relationship to this article
NDSS Symposium 2026 (Wu, Wang, Zhang, Zhang, Niu, Wu, Zhang)	Semantic Cache Poisoning	Primary-source origin of the attack, its four-requirement threat model, and the evaluation data cited throughout this entry.
NDSS Symposium 2025 (Wu, Zhang, Zhang, Wang, Niu, Wu, Zhang)	PROMPTPEEK / KV-cache prompt leakage	Adjacent primary-source evidence for a distinct, read-side side-channel attack against a different cache layer in the same multi-tenant serving stack.
GPTCache (Zilliz, open source)	Reference implementation	The open-source semantic-caching project both papers' attacks were built and evaluated against, and the documented base for the cloud integrations covered here.
OWASP GenAI Security Project	Top 10 for Agentic Applications 2026, ASI06:2026 Memory & Context Poisoning	The broader OWASP risk category this pattern falls under: stored state read back into an agent's context as if it were freshly generated, trusted output.
MITRE, CWE	`CWE-349 Acceptance of Extraneous Untrusted Data With Trusted Data`	General software-weakness classification for a system accepting a crafted cache write alongside legitimate traffic and later treating it as equally trustworthy.
Agent State Attack	Semantic cache poisoning	SSA descriptive framing situating this entry within the Context state surface, alongside RAG poisoning and context-compaction risk.

Related terms

Agent state attack: the umbrella definition, including Context among the listed target states.
RAG poisoning: the adjacent Context-surface attack that corrupts a retrieval corpus rather than a response cache, with the LLM still in the loop.
Compromised summaries and context compaction: another Context-surface risk, targeting an agent's own session history rather than a shared serving-layer cache.
Many-shot context poisoning: a third Context-surface pattern, using volume within a single context window rather than a persisted cache object shared across sessions.