Once RAG grounds LLM outputs in external knowledge bases, the corpus itself becomes an attack surface. The previous five LLM security deep-dives attacked the input (8 injection types), call (8 escalation types), tool surface (8 poisoning types), output (8 leakage types), and memory persistence (8 poisoning types). This article is the sixth dimension — corpus / knowledge base persistence layer — vertical deep-dive, turning “corpus poisoning” from a paper term into a production-actionable attack and defense manual.

The similarity and difference between corpus attacks and memory attacks: both are “persistent”, but corpus is enterprise-shared fact source (RAG retrieval matches affect all users, all queries); memory is agent-self-learning local state (only affects a single agent instance). The RAGShield paper discloses a critical data point: 10 malicious passages (0.04% of corpus) can achieve 98.2% retrieval success rate — one corpus injection can permanently affect all future query outputs.

30-Second Overview

  • RAG corpus is the LLM era’s sixth-dimension persistent attack surface — OWASP LLM Top 10 2026 (released 9-1) lists corpus poisoning in the main category; Agentic Top 10 2026 ASI04 Agentic Supply Chain maps directly
  • 8 corpus poisoning variants (progressing by corpus lifecycle: data source → ingestion → storage → retrieval → output effect): direct malicious passage injection / indirect trusted-source pollution / homograph corpus name squatting / embedding inversion / GraphRAG poisoning / multi-modal RAG / retraining feedback loop accumulation / supply chain package collision
  • 5 2026 real incidents/papers: RAGShield government RAG 10 passages 0.04% → 98.2% retrieval success, Phantom attack same data point, PoisonedRAG 5 passages → 90%+ ASR across NQ/HotpotQA/MS-MARCO, ACL 2026 GraphRAG poisoning, SDAG block-sparse attention defense
  • 7-day defense plan (each ≤ 30 minutes to start): corpus source whitelist + digital signature / embedding drift detection / provenance-verified pipeline / block-sparse attention isolation / GraphRAG hop-wise consistency / multi-modal content hashing / retriever scoring + LLM-as-judge / corpus supply chain provenance
  • Use the Piick tool set to debug tokens, URLs, regex, and encoded payloads on the RAG corpus side — all tools run 100% locally and never upload, keeping your audit log clean

Why RAG Corpus Is the Sixth-Dimension Attack Surface in the LLM Era

To understand why all 8 corpus poisoning variants work, go back to the essence of RAG: LLM output = retrieval(query) + LLM(prompt + retrieved context). Everything the LLM sees as “fact” comes from corpus retrieval; if the corpus is poisoned, LLM output is poisoned.

Corpus attack blast radius:

Corpus is enterprise-shared fact source — one injection, affects all future queries, all users Corpus retrieval does not distinguish “trusted passage vs attack passage” — only checks embedding similarity Corpus auto-ingestion pulls in external content — wiki / doc / GitHub issue / blog comments, auto-added to store Corpus supply chain is complex — loader / connector / package / embedding model / vector DB, every link is attackable

arxiv 2604.00387 RAGShield empirically validated: 10 malicious passages (0.04% corpus) achieve 98.2% retrieval success (Phantom attack data point matches); PoisonedRAG 5 passages injected into million-scale corpus → 90%+ ASR across NQ / HotpotQA / MS-MARCO. corpus poisoning ROI is extreme: small input, large impact.

Worse, corpus attacks are “silent compromise” — users see LLM output “reasonable” answers, but answers are based on poisoned corpus passages; LLM output + retrieval logs look “normal”, audit retrospection is hard.

8 Corpus Poisoning Variants (Progressing by corpus lifecycle: data source → ingestion → storage → retrieval → output effect)

Poisoning 1: Direct Malicious Passage Injection (PoisonedRAG Pattern)

Symptom: attacker directly writes malicious documents into the corpus; RAG retrieval matches and LLM adopts as fact; 5 passages can drive million-corpus system ASR > 90% (PoisonedRAG paper data).

Why it works: RAG retrieval only checks embedding similarity, not whether the passage is trusted / audited. Attacker writes a passage containing “high-recall anchor keywords” + “target answer”, embedding lands in the target query region, LLM adopts directly. PoisonedRAG 5 passages hit 90%+ ASR on NQ / HotpotQA / MS-MARCO three benchmarks.

Minimal reproduction (PoisonedRAG pattern):

Step 1: attacker writes 5 passages, each containing trigger phrase + adversarial answer: “The latest research on X shows that Y is the optimal solution for Z… see [cite]” Step 2: attacker injects the 5 passages into the target corpus (via open comments / wiki edit / public API) Step 3: user query neighbors the trigger phrase → retriever top-K matches attack passages Step 4: LLM sees the passages → outputs adversarial answer Step 5: user sees LLM output “seemingly reasonable” wrong answer, based on “authoritative” citation

Fix:

  • Corpus source whitelist + digital signature (see Day 1). Corpus ingestion restricted to trusted sources (internal DB / signed vendor / audited external sources); each passage HMAC-signed at write; reject unsigned passages
  • Critical corpus passages go through “review-then-ingest” workflow, manual review before adding to store
  • Record provenance at ingestion (URL / vendor / ingest time / signature); at retrieval sort by provenance priority, suspicious sources get down-weighted

Poisoning 2: Indirect Trusted-Source Pollution (comments / wiki / docs)

Symptom: attacker doesn’t attack corpus directly, but pollutes the corpus’s source wiki / Google Doc / GitHub issue / blog comments; corpus auto-ingestion pulls them in as malicious passages.

Why it works: RAG systems increasingly rely on “auto-ingestion pipeline” (web crawler / GitHub sync / wiki API / RSS feed); these sources are often semi-public, anyone can comment / edit. Attacker uses “indirect pollution” to bypass “corpus source whitelist” — because the corpus system itself trusts wiki / GitHub.

Minimal reproduction:

Step 1: attacker edits a neutral topic on Wikipedia / company Wiki, plants hidden text: adds trigger phrase + adversarial answer to a paragraph, text matches wiki style Step 2: company RAG auto-ingestion syncs wiki revisions Step 3: retrieval matches the newly planted paragraph → LLM outputs wrong answer Step 4: RAG system admin only sees “wiki normal update”, cannot identify the attack

Fix:

  • Provenance-verified pipeline (see Day 3). RAG pipeline adds 5-layer provenance verification (borrowing RAGShield approach): ingestion → signing → audit → reweighting → retrieval threshold; mimics software supply chain defense
  • Auto-ingestion sources go through editorial review: “wiki auto-sync” but all new / modified content goes through AI-as-judge review before storage
  • Critical passages use dual-source verification: same topic must appear in 2 independent trusted sources to be trusted

Poisoning 3: Homograph Corpus Name / Namespace Squatting

Symptom: malicious corpus uses homograph name (similar to typosquatting) to register on vector DB marketplace; company ingests by mistake.

Why it works: Vector DB marketplaces (Pinecone / Weaviate / Qdrant, etc.) allow third-party corpus registration; namespace registration review is lax. Attacker registers near-similar name like wikipedia-ml-articles (real is wikipedia-ml); company configures corpus with typo / wrong selection, pulls in malicious corpus.

Minimal reproduction:

Step 1: attacker registers malicious corpus named wikipedia-ml-articles on marketplace (real is wikipedia-ml) Step 2: company RAG engineer configures corpus with typo to wikipedia-ml-articles Step 3: corpus pulled in → malicious passages mixed in Step 4: retrieval matches malicious passage → LLM output polluted

Fix:

  • Corpus source whitelist + digital signature (see Day 1). Corpus registration must be signed, corpus content must have signed manifest; whitelist-only corpus ingest
  • Critical corpus uses “checksum verification”: periodically verify corpus content hash matches official
  • Monitor corpus source distribution anomalies: a corpus share spike → alert

Poisoning 4: Embedding Inversion to Reverse Queries

Symptom: passage embedding vectors in corpus are inversion-attacked → attacker reverses embedding back to original query content, leaking user privacy.

Why it works: Vector DB stores passage embedding vectors; embeddings look “anonymized”, but research proves you can reverse-engineer the original text (query / passage content) from embeddings with high precision. Attacker gets corpus embedding dump → reverses user query history.

Minimal reproduction:

Step 1: attacker gets vector DB dump (leak / over-privilege) Step 2: uses trained inversion model to reverse passage embedding back to passage text Step 3: reversed passages contain sensitive info (user query / internal doc summary) Step 4: attacker splices together complete user query history, leaks enterprise knowledge

Fix:

  • Embedding drift detection (see Day 2). Embedding-mutating passages → alert + manual review; corpus embedding periodic hash comparison, any modification leaves audit log
  • Critical passages use encrypted embedding: encrypted at storage, decrypted at retrieval, even dump can’t recover original text
  • Access control: vector DB API enforce mTLS + short TTL token, minimize leak window

Poisoning 5: GraphRAG Knowledge-Graph Poisoning (ACL 2026)

Symptom: GraphRAG injects spurious entities and relationships during graph construction; pollutes query-specific subgraph → LLM generates wrong answers.

Why it works: GraphRAG builds the corpus into a knowledge graph, then uses graph traversal for retrieval. Graph construction phase is the attack window — attacker writes fake entities + relationships, graph construction auto-includes them. Query-time graph traversal hits fake nodes → LLM sees fake context → outputs wrong answer. ACL 2026 paper HoG-GRAG empirically validated: GraphRAG subgraph is a new attack surface.

Minimal reproduction (ACL 2026 GraphRAG pattern):

Step 1: attacker writes malicious passage claiming a fake entity “HyperTransport Protocol v2” Step 2: GraphRAG construction phase adds fake entity to graph Step 3: user query “transport protocols for high-speed networking” Step 4: graph traversal hits fake entity “HyperTransport Protocol v2” Step 5: LLM outputs “authoritative” answer based on fake entity

Fix:

  • GraphRAG hop-wise consistency check (see Day 5). GraphRAG decomposes multi-hop query into ordered subqueries; consistency check after each hop; poisoning-induced inconsistency → trigger subgraph repair (prune compromised entities + relationships)
  • Critical entities use dual-source verification: each entity must have 2 independent source support
  • Graph construction goes through human-in-the-loop: new entity / relationship requires manual review

Poisoning 6: Multi-Modal RAG Poisoning (image / PDF / audio passage)

Symptom: corpus contains multi-modal passages; attacker uses image steganography / PDF PhantomText / audio-encoded attack payload.

Why it works: Modern RAG corpus is not just text, often contains image / PDF / audio passages. OCR / PDF text extraction / audio transcription all have known attack patterns — attackers use image steganography to hide prompts, PDF hidden text layer, audio-encoded malicious instructions. RAG retrieval converts multi-modal passage to text, LLM sees text containing attack.

Minimal reproduction (PhantomText pattern):

Step 1: attacker creates a PDF, visible text looks normal Step 2: PDF hidden text layer contains trigger phrase + adversarial answer (white text / 0-size / off-screen) Step 3: PDF ingested into RAG corpus Step 4: PDF text extraction pulls out hidden text too (extract-all default) Step 5: LLM sees hidden text → outputs adversarial answer

Fix:

  • Multi-modal content hashing (see Day 6). Image / PDF / audio passages in corpus are hashed + visual OCR-scanned for attack payload before storage; PhantomText and similar attack patterns pre-detected
  • Multi-modal extraction tools (OCR / pdftotext) use safe-config: visible-only / strip-hidden mode
  • Multi-modal passages go through adversarial-robust detection: use dedicated model to scan attack payload

Poisoning 7: Continuous Retraining Feedback Loop Accumulation

Symptom: corpus user-feedback mechanism is abused — attacker repeatedly “reports” a passage as wrong, triggering retraining → gradually accumulating attack passages as authoritative.

Why it works: RAG systems often come with “user feedback” mechanism — users mark passage helpful / not helpful, system uses feedback to retrain embedding model or re-rank weights. Attacker repeatedly marks an attack passage as “helpful”, system adjusts embedding / re-rank → attack passage accumulates more retrieval hits → self-reinforcing loop.

Minimal reproduction:

Step 1: attacker writes a trigger-rich passage + simulates N user accounts repeatedly marking “helpful” Step 2: system retraining → attack passage embedding adjusts, re-rank weight increases Step 3: subsequent real user queries → retriever match probability for attack passage increases Step 4: attack loop continues for months, attack passage weight accumulates to non-negligible Step 5: corpus continuously polluted, admin sees nothing abnormal (feedback data “normal”)

Fix:

  • Retriever scoring + LLM-as-judge (see Day 7). Retriever score top-K retrieval; LLM-as-judge second-review top-K for attack patterns
  • Feedback mechanism goes through anomaly detection: same user agent with massive feedback in short time → rate limit
  • Retraining logic must have “two-way sanity check”: feedback-driven embedding adjustment cannot significantly change top-K retrieval distribution, otherwise revert

Poisoning 8: Supply Chain Package Name Collision (Agentic ASI04)

Symptom: corpus ingestion’s package / connector / loader gets replaced (supply chain attack); loader itself writes malicious passages to store.

Why it works: RAG ingestion usually depends on external packages: web crawler (scrapy / playwright) / connector (confluence / notion / slack) / loader (unstructured / langchain) / embedding model. Any one compromised, whole corpus gets polluted. OWASP Agentic Top 10 2026 ASI04 Agentic Supply Chain Vulnerabilities maps directly.

Minimal reproduction:

Step 1: attacker registers typosquatting package name unstructured-loader (real is unstructured) Step 2: developer pip install with typo → installs malicious package Step 3: RAG ingestion uses it to parse documents → each document secretly plants attack passage Step 4: corpus gradually polluted, no obvious anomaly Step 5: attack continues for months, corpus continuously has malicious passages planted

Fix:

  • Corpus supply chain provenance verification (see Day 7). Corpus ingestion tools (loader / connector / package) go through supply chain provenance verification (signature + publisher identity + SBOM); typosquatting detection
  • Critical packages use pinned version + signature verification; lock file enforced
  • Package management uses enterprise mirror (Sonatype Nexus / JFrog), security scan before mirroring

5 Real 2026 Incidents / Papers

Incident 1: RAGShield Government RAG (arxiv 2604.00387, 2026-04-01)

Paper summary: Government RAG systems face corpus poisoning, simulates 6 attack tiers (T1 external injection → T2 signature forgery → T3 insider threat → T4 loader vulnerability → T5 adaptive evasion → in-place replacement). Key data: 10 malicious passages (0.04% corpus) 98.2% retrieval success (Phantom attack data point); proposes 5-layer defense-in-depth (software supply chain analogy).

Core conclusion: RAG corpus poisoning is structurally similar to software supply chain attacks, requiring provenance-verified defense. Directly maps to Foot-Gun 1 + Foot-Gun 8.

Incident 2: Phantom Attack (2026 H1, Chaudhari et al.)

Attack description: empirically validated 10 adversarial passages (0.04% of corpus) 98.2% retrieval success rate; minimal injection, maximum impact.

Core conclusion: corpus poisoning ROI is extreme — small attack volume, large damage. Directly maps to Foot-Gun 1.

Incident 3: PoisonedRAG Classic Case (NQ / HotpotQA / MS-MARCO)

Paper summary: 5 malicious texts injected into million-scale corpus → 90%+ ASR across 3 benchmark datasets; defined the entire RAG corpus poisoning attack paradigm.

Core conclusion: PoisonedRAG is the “founding paper” of corpus poisoning, 5 passages achieving 90%+ ASR defines the ROI ceiling of corpus attacks. Directly maps to Foot-Gun 1 + Foot-Gun 2.

Incident 4: ACL 2026 GraphRAG Poisoning (HoG-GRAG Defense)

Paper summary: GraphRAG injects spurious entities + relationships during graph construction → pollutes query-specific subgraph → LLM generates wrong answers. HoG-GRAG defense (hop-wise guard) decomposes multi-hop query into ordered subqueries, monitoring hop-wise execution for inconsistencies.

Core conclusion: GraphRAG subgraph is a new attack surface for corpus poisoning, hop-wise consistency check is currently the only effective defense. Directly maps to Foot-Gun 5.

Incident 5: SDAG Block-Sparse Attention Defense (arxiv 2602.04711 v3, 2026-08-26)

Paper summary: Sparse Document Attention RAG; block-sparse attention blocks cross-attention between retrieved documents; attention mask restricts each document to seeing only itself + query. v3 integrates SDAG + RobustRAG / ReliabilityRAG with significantly improved performance.

Core conclusion: eliminates cross-document poisoning attack from the inference layer, no need to detect corpus content, isolates attack by mechanism. Directly maps to Foot-Gun 1 + Foot-Gun 2 defense.

7-Day Defense Plan

Day 1 — Corpus Source Whitelist + Digital Signature (15 minutes to start)

  • Corpus ingestion restricted to trusted sources (internal DB / signed vendor / audited external sources)
  • Each passage HMAC-signed at write (borrowing batch-32 approach); reject unsigned passages
  • Critical corpus passages go through “review-then-ingest” workflow, manual review before storage
  • Record provenance at ingestion (URL / vendor / ingest time / signature); sort by provenance priority at retrieval
  • Homograph corpus name / namespace squatting directly blocked by whitelist

Day 2 — Document Embedding Drift Detection (30 minutes)

  • Passage embedding vectors weekly drift detection (same approach as batch-32 memory drift)
  • Embedding-mutating passages → alert + manual review
  • Corpus embedding periodic hash comparison, any modification leaves audit log
  • Critical passages use encrypted embedding: encrypted at storage, decrypted at retrieval

Day 3 — Provenance-Verified Pipeline (RAGShield Approach, 1 hour)

  • RAG pipeline adds 5-layer provenance verification: ingestion → signing → audit → reweighting → retrieval threshold
  • Mimics software supply chain defense: each passage has builder / signature / build metadata like a “software artifact”
  • Auto-ingestion sources go through editorial review: “wiki auto-sync” but all new / modified content goes through AI-as-judge review before storage
  • Critical passages use dual-source verification: same topic must appear in 2 independent trusted sources

Day 4 — Block-Sparse Attention Isolation (SDAG Approach, 2 hours)

  • Retrieved N documents not allowed cross-attention between each other
  • Attention mask restricts each document to seeing only itself + query
  • Eliminates cross-document poisoning attack from the inference layer, no need to detect corpus content, isolates attack by mechanism
  • Integrate SDAG + RobustRAG / ReliabilityRAG with significantly improved performance
  • Note: this approach requires modifying inference code, suitable for new RAG systems; old systems can add attention mask wrapper

Day 5 — GraphRAG Hop-Wise Consistency Check (2 hours)

  • GraphRAG decomposes multi-hop query into ordered subqueries; consistency check after each hop
  • Poisoning-induced inconsistency → trigger subgraph repair (prune compromised entities + relationships)
  • Critical entities use dual-source verification: each entity must have 2 independent source support
  • Graph construction goes through human-in-the-loop: new entity / relationship requires manual review

Day 6 — Multi-Modal Content Hashing (2 hours)

  • Image / PDF / audio passages in corpus are hashed + visual OCR-scanned for attack payload before storage
  • PhantomText and similar attack patterns pre-detected (visible-only / strip-hidden)
  • Multi-modal extraction tools (OCR / pdftotext) use safe-config: visible-only / strip-hidden mode
  • Multi-modal passages go through adversarial-robust detection: use dedicated model to scan attack payload

Day 7 — Retriever Scoring + LLM-as-Judge + Corpus Supply Chain Provenance (3 hours)

  • Retriever score top-K retrieval; LLM-as-judge second-review top-K for attack patterns
  • Feedback mechanism goes through anomaly detection: same user agent with massive feedback in short time → rate limit
  • Retraining logic must have “two-way sanity check”: feedback-driven embedding adjustment cannot significantly change top-K retrieval distribution, otherwise revert
  • Corpus ingestion tools (loader / connector / package) go through supply chain provenance verification (signature + publisher identity + SBOM); typosquatting detection
  • Critical packages use pinned version + signature verification; lock file enforced

Final Thoughts

RAG corpus poisoning is the “sixth-dimension deep-dive” of piick.cc’s LLM Security series. The LLM Security Quadrilogy + Memory + Corpus covers all “transient” + “persistent” layers on the LLM call chain. Corpus is enterprise-shared fact source — one injection, affects all future queries, all users; corpus poisoning ROI is extreme: small input, large impact.

If your RAG system is already wired into a corpus, start with Day 1 — Corpus Source Whitelist + Digital Signature, spend 30 minutes adding whitelist + HMAC signature to the corpus, that alone blocks 80% of direct injection attacks (PoisonedRAG / Phantom class). Then follow the 7-day plan forward.

RAG corpus-era security cannot be solved by any single defense — provenance + signing + drift detection + block-sparse attention + GraphRAG consistency + multimodal hashing + retriever-as-judge + supply chain verification eight-layer independent fallback. This article’s 8 foot-guns + 5 real incidents + 7-day plan are the most stable fallback available now; the real protocol-layer standards (RAG corpus provenance specification / signed retrieval manifest) may have to wait for the next generation of RAG protocols.

The next phase of piick.cc’s LLM Security series will enter vertical deep-dives: [MCP federation cross-server attacks] / [Agent output via MCP federation exfiltration] / [Agent DOM automation] / [Agent vision manipulation], etc. If you have a specific direction you want to see, let me know.

Debugging tokens, URLs, regex, and encoded payloads on the RAG corpus side? Use the Piick tool set:

  • /tools/jwt-decoder/ — locally read JWT capability tokens in corpus ingestion, confirm scopes are not widened (echoes Day 1 provenance)
  • /tools/url-encoder-decoder/ — locally check whether corpus source URL is bypassed by double encoding; troubleshoot Foot-Gun 2 (indirect pollution)
  • /tools/regex-tester/ — locally test provenance whitelist regex; troubleshoot Foot-Gun 3 (homograph squatting)
  • /tools/text-encoder/ — Base64 / hex detection of encoded attack payloads in multi-modal passages; echoes Foot-Gun 6

All tools run 100% locally; no file is uploaded to any server, keeping your audit log clean.