MCP Context Poisoning [Deep Dive] in Agentic AI 2026

The most important MCP security story of early 2026 was not a classic memory-corruption bug. It was a trust bug. Research into ContextCrush showed that an MCP server can act as a delivery lane for attacker-controlled instructions, even when the server itself exposes only narrow, read-only tools. In agentic systems, that is enough: once poisoned context lands in the model’s working memory, the agent can exfiltrate secrets, invoke other tools, or destroy local state under the banner of “helpful” automation.

• ContextCrush was disclosed on March 5, 2026 after discovery on February 18.
• The exploit path was content poisoning, not direct code execution on the MCP server itself.
• CVE-2026-35568 independently proved MCP implementations still fail basic trust-boundary checks.
• The MCP transport spec already warns servers to validate Origin headers against DNS rebinding.

CVE Summary Card

Incident at a glance

• Primary incident: ContextCrush, disclosed by Noma Security on March 5, 2026.
• Affected pattern: user-generated or third-party content delivered through an MCP server into an agent’s live context.
• Observed impact in research: secret discovery, exfiltration to an attacker-controlled repository, and destructive local cleanup commands.
• Reported status: responsibly disclosed and patched before public release; Noma reported no evidence of exploitation in the wild.
• Related CVE: CVE-2026-35568 in the MCP Java SDK, published April 7, 2026, fixed in 1.0.0.

Why include a CVE in a context-poisoning story?

ContextCrush is the cleaner case study for adversarial memory injection, but CVE-2026-35568 matters because it shows the same class of design failure from another angle: MCP systems are brittle wherever they trust the wrong source. In the Java SDK case, the gap was transport trust. In ContextCrush, the gap was semantic trust.

The official GitHub advisory for CVE-2026-35568 says the Java SDK performed no Origin validation before 1.0.0, despite the MCP transport specification requiring it. That let a malicious website reach a local or network-private MCP server through DNS rebinding and make tool calls as if it were a local AI client. Different exploit surface, same lesson: if the protocol boundary is porous, agent privileges become attacker privileges.

Vulnerable Code Anatomy

The core mistake

Most teams still reason about MCP tools as if they were typed APIs. They are not. In an agent loop, tool output is also model input, and model input is often treated as policy-bearing context. That makes runtime data part of the control plane.

The minimal vulnerable pattern looks like this:

// Conceptual only: illustrates the trust bug
const toolResult = await mcp.callTool('query-docs', { library: 'target-lib' });

// Vulnerability: third-party content is merged into high-trust context
conversation.push({
  role: 'system-like-context',
  content: toolResult.text
});

// Agent now plans with poisoned context in memory
const nextAction = await model.plan(conversation);
await execute(nextAction);

Nothing here looks dramatic. The server returned text. The agent read it. The model planned. The executor acted. But this is exactly where the exploit lives.

Why read-only servers are still dangerous

Noma’s write-up is useful because it breaks a common misconception. Context7 exposed only documentation lookup tools. It did not need a built-in shell, filesystem writer, or HTTP client to become a weapon. The dangerous capability existed elsewhere in the agent runtime:

• The MCP server delivered content.
• The IDE agent treated that content as guidance.
• The agent already had access to local files, Bash, GitHub, or other MCP tools.
• The model stitched those capabilities together on the attacker’s behalf.

That is why “least privilege per tool” is necessary but insufficient. The composition layer is where privilege is reassembled.

The second anatomy lesson: transport trust

The Java SDK advisory sharpens the point. The MCP spec’s HTTP transport warning explicitly says servers MUST validate the Origin header and SHOULD bind locally to 127.0.0.1 instead of 0.0.0.0. Before 1.0.0, the Java SDK failed that requirement, enabling DNS rebinding in local or adjacent-network scenarios. In both cases, the architectural bug is the same: the system treated hostile input as sufficiently trusted to drive privileged actions.

Attack Timeline

• February 18, 2026: Noma Labs discovered and probed the ContextCrush vulnerability and delivered a technical report to Upstash.
• February 19, 2026: Upstash accepted the findings and started remediation.
• February 23, 2026: Noma reported a production fix with rule sanitization and guardrails.
• March 5, 2026: Noma publicly disclosed ContextCrush.
• April 7, 2026: GHSA-8jxr-pr72-r468 and CVE-2026-35568 were published for the MCP Java SDK.
• April 14, 2026: NVD recorded the Java SDK issue with CWE-346 and affected versions below 1.0.0.

Viewed together, these dates matter because they show the problem is not isolated to one vendor or one exploit trick. The ecosystem is now seeing both content-lane poisoning and transport-lane trust failures in production MCP stacks.

Exploitation Walkthrough

Conceptual path only

1. An attacker publishes or controls content that an MCP server is allowed to relay, such as documentation, rules, notes, tickets, or memory entries.
2. The content mixes legitimate-looking material with embedded instructions aimed at the agent, not the human reader.
3. A developer asks the agent to fetch that content through an installed MCP server.
4. The MCP server returns the poisoned material through a trusted tool response.
5. The agent merges that response into its planning context without provenance labels or policy separation.
6. The model interprets the attacker’s instructions as task-relevant guidance and plans follow-on actions.
7. The executor uses the agent’s existing privileges to read secrets, call other tools, modify files, or send data off-host.

Why this works so reliably

• Tool responses often inherit more trust than web content because users explicitly installed the server.
• Long-lived agent memory lets a poisoned instruction persist across multiple reasoning turns.
• Cross-tool orchestration means one harmless-looking response can trigger actions in completely different tools.
• Ranking signals, trust scores, and popularity badges can manufacture false legitimacy around attacker content.

OWASP’s MCP Tool Poisoning write-up captures the root cause well: the trust gap sits between connection-time review and runtime execution. Teams may inspect a server’s tool list once, then blindly pass later responses into the model as if the runtime channel were equally safe. It is not.

Hardening Guide

1. Split data context from instruction context

• Never inject raw tool output into a high-trust system or planner channel.
• Tag every memory block with source, trust tier, timestamp, and transformation history.
• Route untrusted results through a summarizer that is explicitly forbidden from emitting executable instructions.

2. Enforce transport hygiene from the MCP spec

• Validate Origin on every HTTP transport request.
• Bind local servers to 127.0.0.1, not 0.0.0.0, unless exposure is intentional and protected.
• Add authentication even for “internal” MCP services.
• Upgrade vulnerable implementations, including MCP Java SDK versions below 1.0.0.

3. Put policy between the model and the executor

• Require a separate authorization layer for file reads, network egress, and destructive operations.
• Demand human approval for multi-step actions involving secrets, credentials, repositories, or shell execution.
• Deny cross-tool pivots by default unless the workflow explicitly allows them.

4. Sanitize and constrain third-party content

• Strip hidden instructions, metadata tricks, and tool-invocation patterns from retrieved content.
• Quarantine user-generated rules, comments, and notes before they reach long-term memory.
• Log original and transformed versions for forensic review, but protect secrets in those logs.

If your incident workflow needs to store suspicious outputs for analysis, run captured samples through TechBytes’ Data Masking Tool before sharing them across teams or tickets.

5. Reduce agent blast radius

• Separate browsing, coding, and deployment agents into different sandboxes and identities.
• Remove dangerous helper capabilities such as arbitrary evaluation unless they are essential.
• Block metadata services, RFC1918 destinations, and local admin panels from browser-capable tools.
• Use ephemeral workspaces and short-lived credentials so poisoned memory has less value.

Architectural Lessons

Instruction/data separation has to be real

Agent builders keep rediscovering the same security law: natural language collapses control and content into one channel. If you do not reintroduce that separation in architecture, the attacker will do it for you. The fix is not “better prompting.” The fix is typed trust boundaries around what the model may read, remember, and act on.

Popularity is not provenance

ContextCrush also showed how weak marketplace reputation signals are in agent ecosystems. Stars, badges, and adoption stats say almost nothing about the safety of runtime content. A trusted transport carrying untrusted user content is still an untrusted system.

Memory is part of the attack surface

Once agents retain summaries, notes, or tool results across turns, the compromise becomes durable. That makes memory stores closer to executable policy caches than passive logs. Memory needs expiry, source labels, quarantine states, and revocation.

Security controls must live above the model

The model can help classify risk, but it cannot be the final guardrail for its own permissions. Strong agent systems put deterministic controls in front of dangerous tools and behind dangerous outputs. That means:

• policy engines outside the model,
• typed action brokers,
• network segmentation,
• provenance-aware memory,
• and explicit approval gates for irreversible actions.

The larger lesson is simple. MCP context poisoning is not a weird corner case. It is what happens when agent platforms treat context as harmless text instead of executable influence. The teams that win in 2026 will be the ones that design for hostile context by default.