Description

tiger-slack started its MCP HTTP transport without enabling the host allow-list the underlying SDK provides. mcp/src/httpServer.ts called the shared httpServerFactory helper and never set the DNS-rebinding-protection option, so the transport accepted a request whatever host it named, and a page in a browser could point a name it controlled at the address the server was bound to and drive the locally reachable Slack MCP server through the visitor's browser. The fix passes the option explicitly alongside a dependency update; the update alone would not have closed it. The repository publishes no release that brackets the fix, so the affected boundary is the commit preceding it.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-08-27T17:20:52.467Z",
  "pubdate": "2026-08-27T17:20:52.467Z",
  "executiveSummary": "The tiger-slack repository contains a critical security vulnerability involving the MCP HTTP transport mechanism. The implementation fails to enforce a host allow-list, exposing the local MCP server to DNS-rebinding attacks.\nThis vulnerability allows a remote attacker, via a malicious website visited by a user, to bypass the Same-Origin Policy (SOP) by manipulating DNS resolution to map a controlled domain to the local loopback address (e.g., 127.0.0.1).\nOnce the browser is tricked into interacting with the local server, the attacker can issue unauthorized commands to the Slack MCP server, effectively performing actions on behalf of the victim.\nThe risk is significant as it leverages local network trust to execute arbitrary operations via the MCP protocol. Exploitation requires only that a user navigates to an attacker-controlled web page while the vulnerable tiger-slack instance is running. No prior authentication is required as the server lacks adequate origin validation.",
  "technicalDetails": "The vulnerability resides within mcp/src/httpServer.ts, where the MCP HTTP transport is initialized using a shared httpServerFactory helper. The root cause is the omission of the required 'DNS-rebinding-protection' configuration option during the transport initialization process.\nIn a standard MCP HTTP transport configuration, the SDK provides mechanisms to validate the 'Host' header of incoming requests to ensure they match authorized origins. By failing to set the protective flag, the server blindly accepts requests regardless of the 'Host' header value provided by the client.\nThe exploitation flow follows the mechanics of a classic DNS-rebinding attack: 1. The attacker registers a domain under their control and configures the DNS server with a very low Time-to-Live (TTL) value. 2. A victim navigates to the malicious domain. 3. The attacker's script triggers an initial request to the domain, causing the browser to resolve the IP address correctly. 4. The attacker then modifies the DNS record to point to '127.0.0.1'. 5. Subsequent requests from the attacker's script are sent to the newly resolved local address.\nBecause the MCP server does not enforce host allow-lists or check the 'Host' header, it treats the request as a legitimate command. The browser, under the impression that it is communicating with the original malicious domain, bypasses SOP constraints and facilitates the delivery of the malicious payload to the local service.\nThe vulnerable component is the MCP HTTP transport initialization logic. The affected range comprises all commits preceding the corrective patch. The fix involves explicitly passing the 'DNS-rebinding-protection' option to the factory function. Simply updating underlying dependencies is insufficient, as the implementation code itself must be modified to enable the security control.\nThe post-exploitation impact allows the attacker to drive the Slack MCP server, potentially accessing private channels, exfiltrating information, or sending unauthorized messages, depending on the permissions and functionality exposed by the MCP interface."
}