CVE-2026-81315: MCP DNS-rebinding origin check in AshAi is bypassed by a spoofed X-Forwarded-Proto header
Origin Validation Error vulnerability in ash-project ashai allows a malicious web page to bypass the MCP server's DNS-rebinding protection and issue cross-site requests to a user's local MCP server with that user's actor.
In AshAi.Mcp.Server, with the default allowedorigins: nil, originallowed?/3 accepts an origin when uri.host == conn.host and the forwarded scheme is https. Both values are attacker-controlled: conn.host comes from the Host header and the scheme is read from the raw x-forwarded-proto header with no trusted-proxy check. Under DNS rebinding the browser sends the attacker's origin and a matching host, and page JavaScript may set X-Forwarded-Proto: https, so the check passes with no TLS or proxy involved. The fix trusts only localhost origins by default; other origins require an explicit allowedorigins allowlist.
This issue affects ashai: from 0.8.0 before 1.0.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_aito a version that resolves this vulnerability.Fixed in 1.0.0 - Configuration
Ensure AshAi.Mcp.Server uses the default behavior that trusts only localhost origins when allowed_origins is nil; do not set an allowlist that would permit attacker-controlled origins.
AshAi.Mcp.Server allowed_origins = nil (default)
Event History
Frequently Asked Questions
Which deployments are exposed?
AshAi versions from 0.8.0 before 1.0.0 are affected when using AshAi.Mcp.Server with the default allowed_origins: nil behavior. The vulnerable default accepts origins based on attacker-controlled Host and X-Forwarded-Proto headers.
What does an attacker need to exploit this?
An attacker needs to lure a user to a malicious web page and use DNS rebinding to target that user's local MCP server. The attack can then send cross-site requests using the user's actor; no TLS connection or trusted proxy is required.
Does configuring allowed_origins mitigate the issue?
Yes. The fix changes the default to trust only localhost origins, and non-localhost origins must be explicitly listed in an allowed_origins allowlist. Upgrading to 1.0.0 or later applies this safer behavior.
What can be done before upgrading?
Configure an explicit allowed_origins allowlist rather than relying on allowed_origins: nil. Limit the allowlist to the origins that legitimately need access to the MCP server.