CVE-2026-81102 in mcp-server-dash
Summary
by MITRE • 08/27/2026
The Dash MCP server bound its listener to the loopback address but never checked the host a request named. src/mcp_server_dash.py constructed the server for its network mode with the interface restricted to loopback and no transport-security settings, so a name that had been pointed at the loopback address still reached the listener while carrying the attacker's host name. A page in a visitor's browser could therefore drive the local server and invoke its company-search and file-detail tools under the Dropbox credential the server holds. Only the network mode was reachable this way; the standard input mode was not. The fix supplies transport-security settings that enable host checking and allow only the loopback name and port, rejecting other hosts before a tool runs. The repository publishes no versions, so the affected boundary is the commit preceding the fix.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The Dash MCP server contained a critical security misconfiguration related to network binding and request validation that allowed for unauthorized local access despite apparent restrictions on its listening interface. Although the server was configured to bind exclusively to the loopback address, effectively limiting incoming connections to those originating from the same machine, it failed to validate the Host header included in HTTP requests. This architectural flaw meant that any client capable of sending a request to localhost could manipulate the perceived origin of the traffic by specifying an arbitrary hostname within the request headers. The server logic did not cross-reference this provided host name against its actual binding configuration before processing the request, creating a discrepancy between where the connection physically arrived and how the application interpreted the source identity.
This vulnerability enables a scenario known as Host Header Injection or HTTP Request Smuggling in specific contexts, allowing an attacker to bypass intended access controls through social engineering or cross-site scripting vectors within local applications. Since the server holds Dropbox credentials with significant privileges, including company-search and file-detail tool capabilities, this flaw poses a severe risk to data confidentiality and integrity. An adversary could craft a malicious web page that, when visited by a user on the same machine as the running Dash MCP server, sends requests to localhost while spoofing trusted hostnames or exploiting browser-based request mechanisms. Because standard input mode was not affected, the attack surface is strictly limited to network interactions, but within that boundary, an attacker could potentially exfiltrate sensitive corporate data or perform unauthorized file operations under the identity of the service account.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control and CWE-15 External Control of System or Configuration Setting. The failure to validate the Host header against expected values is also characteristic of vulnerabilities often mapped to MITRE ATT&CK techniques involving Server-Side Request Forgery (SSRF) variants where local services are abused, specifically T1090 Proxying which can be used to route traffic through trusted interfaces. The lack of transport security settings further exacerbates the risk by allowing unencrypted communication that could potentially be intercepted or manipulated if other network layers were compromised, although the primary vector here is direct localhost exploitation via browser-driven requests.
The remediation strategy implemented in the fix addresses these deficiencies by enforcing strict host checking and enabling robust transport-security configurations. By restricting accepted connections to only those matching the specific loopback name and port combination, the server now validates that incoming requests originate from an expected source context before executing any tools or accessing sensitive data stores like Dropbox credentials. This ensures that even if a request arrives at localhost with a spoofed header, it will be rejected unless it matches the authorized configuration parameters. Organizations relying on this software should ensure they are running versions post-fix and verify that no other services expose similar host validation weaknesses in their local development or production environments to prevent potential data breaches stemming from improper access control mechanisms.