Origin and host validation for MCP servers (DNS rebinding)
ATR evaluates whether a local server validates requests to reduce DNS rebinding exposure.
Why it matters
Agent-specific protocol risks matter. For example, a local MCP server that does not validate the requesting origin and host may be exposed to DNS rebinding.
Example: risk in one of six components
An open-source browser-automation agent contains six components: one MCP server and five skills that support the project’s own development workflow. ATR assessed each one separately. The five skills had no vulnerable findings of their own. The MCP server had three, and the clearest is a high-severity finding under ATR-M0003, origin and host validation.
The MCP server includes a local bridge that accepts WebSocket connections on localhost and never checks the Origin header. A browser lets any web page open a WebSocket connection to any host, so only the server’s own Origin check can refuse one, and this bridge has none. A page that connects before the agent’s browser extension does is accepted as the extension, and the bridge then sends it the next task, including the user’s LLM API key. The report cites four code locations as evidence, each with a short excerpt.
The finding tells a developer what to change: reject connections from any origin other than the extension’s, or require a per-session secret that the extension presents when it connects. It tells a security reviewer where the risk sits: in the MCP server, not in the five skills, which do not need the same remediation.
How the rule decides
| Threat | A web page open in the user’s browser uses DNS rebinding to send requests to an MCP server on the user’s machine. |
|---|---|
| Vulnerable when | An HTTP or SSE MCP listener accepts requests without checking the Origin header (and the Host header, if it listens beyond loopback), and a rebound page would gain something of the user’s: a tool with file, process, network, or credential access; a listener reachable beyond loopback; or a response that carries a credential. |
| Safe lookalike | A listener with no Origin check that listens on loopback only, whose tools work only on the caller’s own input and return no credentials. A rebound page gains a session of its own and nothing of the user’s, so the false-positive guard grades it secure and records the missing check as hardening. |
| Code shape | A configuration that allows every origin with credentials, such as cors({ origin: ‘*’, credentials: true }), is flagged; an explicit list of allowed origins is not. |
| Required evidence | Execution reachability, mitigation analysis, attacker trigger capability, and security impact. |
| Severity | High. CWE-942 and CWE-346. |
In the registry
ATR evaluated this on 15 MCP servers in the 20 published reports, as of Nov. 9th, 2026, and found an issue in 8, across 7 reports.
Each report shows the exact file and lines, why the issue matters, and the recommended fix, with a fix prompt you can paste into your coding agent. Browse the reports.
Questions
What does ATR check for origin and host validation?
ATR evaluates whether a local server validates requests to reduce DNS rebinding exposure. Each MCP server is assessed against 26 rules: 14 common, one guardrail, and 11 MCP-specific rules.
Why does origin and host validation matter?
Agent-specific protocol risks matter. For example, a local MCP server that does not validate the requesting origin and host may be exposed to DNS rebinding.
How often does the registry find it?
ATR evaluated this on 15 MCP servers in the 20 published reports, as of Nov. 9th, 2026, and found an issue in 8, across 7 reports.
How do I check my own MCP server?
Request a scan at bluerock.io/scan. Your first scan is free. Each MCP server is assessed against 26 rules: 14 common, one guardrail, and 11 MCP-specific rules.
Source: BlueRock, Component Level Security Analysis for MCP Servers, Agent Skills and Plugins (Oct. 22nd, 2026).