CVE-2026-81315 in ash_ai
Summary
by MITRE • 08/31/2026
Origin Validation Error vulnerability in ash-project ash_ai 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 allowed_origins: nil, origin_allowed?/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 allowed_origins allowlist.
This issue affects ash_ai: from 0.8.0 before 1.0.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in the ash-project ash_ai library represents a critical origin validation error that undermines the security model of Multi-Protocol Communication (MCP) servers by allowing malicious web pages to bypass DNS rebinding protections and execute cross-site requests against local services. This flaw specifically targets the AshAi.Mcp.Server component, where the default configuration allows for an overly permissive interpretation of request origins due to insufficient validation of HTTP headers. The core technical failure lies in the origin_allowed?/3 function, which determines whether a given incoming request should be accepted based on its source context. Under normal secure configurations, this check would verify that the requesting origin matches expected trusted domains and operates over a verified transport layer such as TLS. However, the implementation relies on comparing the uri.host against conn.host while simultaneously checking if the forwarded scheme is https. Both of these values are directly controllable by an attacker through standard HTTP headers without requiring any privileged access or complex exploitation techniques beyond basic web interaction.
The operational mechanism of this vulnerability exploits how browsers handle cross-origin requests and how servers interpret proxy-related headers during DNS rebinding attacks. In a typical scenario, the conn.host value is derived from the Host header sent by the client's browser, while the scheme is extracted from the raw x-forwarded-proto header without any verification that the request actually passed through a trusted reverse proxy or load balancer capable of stripping or setting such headers securely. An attacker can craft a malicious web page that initiates requests to the local MCP server running on the victim's machine. By leveraging DNS rebinding, the attacker ensures that the domain name resolves first to an external address and then switches to resolve to localhost addresses like 127.0.0.1 or ::1 within the same session. The browser sends the attacker-controlled origin along with a Host header matching the local IP address. Crucially, because the server blindly trusts the x-forwarded-proto header for scheme determination, the JavaScript in the malicious page can simply set this header to https, causing the validation logic to believe the connection is secure and originating from an allowed source. This effectively neutralizes the DNS rebinding protection intended by the framework's default settings.
The impact of this vulnerability allows a remote attacker to issue cross-site requests to the user's local MCP server using that user's active actor credentials or session context. Since the validation logic fails to distinguish between legitimate proxy-mediated traffic and direct browser-originated traffic, any web page hosted on an external domain can interact with sensitive internal APIs as if it were part of a trusted origin. This leads to unauthorized data access, potential configuration tampering, or execution of actions within the MCP server environment that should be restricted to specific local applications or authenticated users. The absence of TLS verification in this context means that even though the protocol is labeled https via header manipulation, there is no actual encryption or certificate validation occurring between the browser and the server for these rebinding requests, leaving the communication susceptible to interception if other network conditions allow it, although the primary risk here is unauthorized access rather than eavesdropping.
Mitigation strategies must focus on tightening origin validation logic by removing reliance on untrusted headers for security-critical decisions. The recommended fix involves restricting default allowed origins strictly to localhost-based schemes and requiring explicit configuration of an allowed_origins list for any external domains, ensuring that only pre-approved sources can interact with the MCP server. Developers should implement strict proxy trust mechanisms if x-forwarded-proto is necessary, such as verifying that requests originate from known internal IP ranges or trusted reverse proxies before accepting forwarded headers. Additionally, implementing Content Security Policy (CSP) directives and SameSite cookie attributes on associated endpoints can provide defense-in-depth layers to prevent unauthorized cross-origin data exfiltration even if the origin check fails. This vulnerability aligns with CWE-346 regarding Origin Validation Errors and falls under ATT&CK technique T1505.003 for Server Side Request Forgery via DNS rebinding, highlighting the importance of robust input validation in web-facing services that interact with local infrastructure. The issue affects versions of ash_ai from 0.8.0 up to but not including version 1.0.0, necessitating an immediate upgrade or configuration adjustment to prevent exploitation by malicious actors targeting users running affected instances locally.