Anthropic's Model Context Protocol (MCP) lacks cryptographic provenance for tool results, creating a confused deputy vulnerability. The official fetch server returns attacker-controlled Markdown directly to a model's context window without labeling it untrusted.
Key facts
- MCP tool results lack cryptographic provenance.
- Official fetch server returns Markdown without trust labels.
- DNS rebinding bypasses URL allowlists via TTL zero.
- ToolAnnotations are advisory, not security boundaries.
- Attack requires only serving content at a fetchable URL.
The Model Context Protocol (MCP) is the connective tissue between LLMs and external systems — filesystems, databases, APIs, browsers, internal tooling. In a well-functioning agentic deployment, MCP lets a model read documents, query databases, and take actions in the world. In an adversarial deployment, MCP becomes the mechanism by which attacker-controlled content reaches a model's context window and convinces it to take actions the user never authorized. According to The MCP Confused Deputy
Key Takeaways
- MCP has a confused deputy vulnerability: tool results lack provenance, allowing injection.
- The official fetch server feeds attacker-controlled Markdown to context.
The Structural Provenance Gap
The confused deputy is a classic access-control concept: an entity with legitimate authority is manipulated by an untrusted party into exercising that authority on the untrusted party's behalf. In MCP, the confused deputy is the model itself.
Here is the structural problem: when an MCP tool call returns a result, the protocol carries the content of that result into the model's context window. It does not carry cryptographically attestable information about where that content came from, who produced it, or whether it has been tampered with in transit. The model receives a tool_result and must decide how to act on it based on its content — but the content could come from a trusted server, a compromised server, a DNS-rebinded endpoint, or a webpage that an attacker controls and has stuffed with instruction text designed to override the model's behavior.
The MCP specification includes a ToolAnnotations object — fields like readOnlyHint, destructiveHint, idempotentHint — intended to communicate properties of tools to clients. The specification is explicit that these annotations are advisory and not security boundaries. They can be set by the server and have no verifiable binding to actual tool behavior. A malicious or compromised server can annotate a destructive write operation as readOnly. An instruction-injected tool result can include fabricated annotations in its text. Neither the client nor the model can verify them cryptographically.
The result is a protocol where the model is asked to make trust decisions about content for which the protocol provides no trustworthy provenance signal.
Attack Surface: Fetch Server and DNS Rebinding
The reference mcp-fetch-server" class="entity-chip">MCP fetch server — the official Anthropic-maintained server for web browsing tool calls — accepts a URL, fetches the content, converts the HTML to Markdown, and returns it as a tool_result. The model receives this Markdown and processes it as part of its context.
Consider what happens when the URL being fetched is attacker-controlled. The attacker can place arbitrary text in the page, including instructions formatted to look like system-prompt or tool-definition content, text that references other tool names in the model's context and instructs the model to call them with specific arguments, content that mimics the format of legitimate tool results to build false context, and instructions to exfiltrate information from context by encoding it in a follow-up URL fetch.
This is not a hypothetical. The fetch server converts web content to Markdown without sanitizing or labeling it as untrusted external content — it lands in the model's context with the same structural weight as system instructions or legitimate tool results. The model has no reliable mechanism to distinguish "this is content I fetched from an external page" from "this is an instruction from my operator."
The attack does not require compromising an MCP server. It requires only the ability to serve content at a URL the model will be asked to fetch — which in many agentic workflows is directly controlled by user input or by attacker-controlled content in previously fetched documents.
DNS rebinding attacks against MCP create a distinct and particularly dangerous attack path. An attacker registers a domain and configures a DNS server that initially resolves it to a public IP. The MCP fetch server checks the URL — it resolves to a public IP, passes any allowlist or block check, and proceeds. The attacker's DNS server drops the TTL to zero and rebinds the domain to an internal IP address — 192.168.x.x, 10.x.x.x, or 172.16-31.x.x — typically the IP of an internal service that the MCP server can reach from its network position. When the MCP server makes the HTTP request, the DNS lookup now resolves to the internal IP. The fetch server connects to the internal service and returns its content to the model.
This bypasses most URL-based filtering because the filtering happens at allowlist check time (public IP), not at fetch time (internal IP). The MCP server becomes an involuntary proxy to internal services, and the attacker now has the model reading the output of those internal services.
The footgun is particularly sharp in self-hosted agentic deployments where the MCP server runs inside the network perimeter and has access to internal APIs, documentation systems, internal dashboards, or configuration management endpoints that are not exposed publicly.
Detection Rules and Mitigations
The following are concrete, loggable signals for MCP deployments. These should be implemented at the MCP proxy layer, in SIEM rules, or in the agent monitoring infrastructure.
Instruction injection detection:
- Rule: Tool result content contains system-prompt-like structure. Alert when a tool_result payload contains strings that match system-prompt formatting patterns: XML-like role tags (
<system>,<instructions>,[INST]), markdown headers framing instructions (## New Instructions,## Override), or explicit references to model roles. - Rule: Tool result references other tool names with arguments. Alert when the text content of a tool_result includes strings that match tool names registered in the current MCP session, especially when followed by argument-like structures.
- Rule: Tool result size exceeds threshold relative to request. Large tool results — particularly from fetch operations on relatively simple URLs — may indicate content stuffed with injection text.
DNS rebinding detection:
- Rule: Destination IP of MCP fetch resolves to RFC1918 space. Log the resolved IP address at the time of the HTTP connection, not at URL parse time. Alert when a fetch to a non-private hostname results in a TCP connection to 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
- Rule: DNS TTL below threshold on MCP-fetched domains. Log TTL values for all DNS resolutions made by the MCP fetch server. A TTL of zero or below 30 seconds on a non-CDN domain is a rebinding preparation signal.
- Rule: HTTP redirect chain ending at internal IP. Detect redirect chains where an initial fetch to a public IP eventually redirects to an internal endpoint.
Behavioral anomaly detection:
- Rule: Tool call sequence diverges from established session pattern. Alert when a new tool call type appears immediately after a fetch_url result — consistent with successful injection.
- Rule: Tool call to privileged write/execute tools without prior user message. Flag for review if a tool with destructive or write capability is called without a corresponding user instruction in the conversation turn that triggered it.
- Rule: Data exfiltration via chained fetch calls. Alert when fetch_url tool calls include URL query parameters or fragments that contain strings also present in earlier tool results or context.
Mitigations beyond detection:
- Label untrusted content explicitly in context. The model prompt architecture should clearly delineate tool results from external sources as untrusted. Wrapping external fetch results in a structured tag —
<external_content source="untrusted">— and training or prompting the model to treat such content as data, not instructions, reduces but does not eliminate injection risk.
What to watch
Watch for Anthropic's response to this vulnerability disclosure — whether they add provenance fields to the MCP spec or release a security-focused update to the fetch server. Also monitor for third-party MCP implementations adopting trust-labeling patterns in their prompt architectures.
Source: dev.to
[Updated 14 Jul via devto_mcp]
A new third-party MCP server for X (Twitter), built by Faruk Kolip in ~600 lines of TypeScript, demonstrates that even simple, auditable MCP implementations can achieve rapid adoption — 500+ npm downloads in two weeks — while relying on a public, undocumented JSON endpoint (cdn.syndication.twimg.com/tweet-result) with no authentication [per Faruk Kolip]. The server uses pure functions, no database or session state, and publishes via npm for zero-setup execution via npx. This real-world case underscores the distribution advantage of MCP over REST APIs but also highlights that many MCP servers are built on undocumented, change-prone data sources, amplifying the confused deputy risk: if such a source is compromised or altered, injected content flows directly to the model's context.
