DNS Rebinding Bypass of MCP Server Origin Validation in ash_ai

Technical Analysis

AshAi.Mcp.Server's origin_allowed?/3 function, when allowed_origins is nil (the default), approves a request if the request's Host header matches the URI host and the forwarded protocol header claims https. Because conn.host is derived directly from the client-supplied Host header and x-forwarded-proto is read from a raw, unauthenticated header rather than validated against a trusted proxy list, an attacker can use classic DNS rebinding: lure a victim to a malicious page, have the page's DNS entry rebind to 127.0.0.1 after initial load, and issue JavaScript fetch requests with a spoofed X-Forwarded-Proto: https header. This satisfies the origin check with no TLS or legitimate proxy involved, letting the attacker's page send authenticated MCP tool-invocation requests to the victim's local MCP server using the victim's session/actor context. The attack crosses the browser-to-local-agent trust boundary, effectively turning the browser into a proxy that can invoke privileged MCP tools/actions on behalf of the user without their consent.

Affected Systems

ash_ai; protocols: MCP

Detection Signatures

• Requests to local MCP server endpoints with mismatched or suspicious Host headers relative to expected domains
• Unexpected X-Forwarded-Proto: https headers on requests not passing through a legitimate reverse proxy
• MCP server logs showing origin validation passes for non-localhost or unexpected hosts
• Rapid DNS resolution changes for domains recently visited by users running local MCP servers (classic DNS-rebinding signature)
• Cross-origin fetch/XHR requests targeting localhost or 127.0.0.1 ports from unrelated third-party domains

Remediation Steps

1. 1

   Upgrade ash_ai

   Update to ash_ai version 1.0.0 or later, which trusts only localhost origins by default and requires explicit allowlisting for other origins.

2. 2

   Configure allowed_origins explicitly

   Set the allowed_origins configuration to a strict, explicit allowlist of trusted origins rather than relying on defaults, even after upgrading.

3. 3

   Validate trusted proxy headers

   Only trust X-Forwarded-Proto and similar forwarded headers when the request genuinely originates from a known, trusted reverse proxy; strip or ignore these headers from direct client connections.

4. 4

   Bind MCP server to localhost with additional auth

   Ensure local MCP servers require an additional authentication token or nonce beyond origin checks, since browser-based origin/Host validation alone is insufficient to prevent DNS rebinding.

5. 5

   Monitor for DNS rebinding patterns

   Deploy network or DNS-layer monitoring to detect rapid re-resolution of external domains to internal/loopback addresses, a hallmark of DNS rebinding attacks.