tiger-slack MCP Server DNS Rebinding via Missing Host Allow-List

Technical Analysis

The vulnerability stems from mcp/src/httpServer.ts calling the shared httpServerFactory helper without setting the DNS-rebinding-protection/host allow-list option that the underlying MCP SDK exposes. Because the HTTP transport accepted requests for any Host header, an attacker-controlled webpage can use DNS rebinding to resolve an attacker-owned domain to the loopback or LAN address where the MCP server listens, bypassing same-origin protections in the victim's browser. Once rebound, the browser's JavaScript can send crafted HTTP requests directly to the local Slack MCP server, invoking its tools (e.g., posting messages, reading channels) using the server's authenticated Slack session, effectively turning the victim's browser into a proxy that crosses the trust boundary between untrusted web content and a privileged local agent tool server. This is a classic local-service DNS-rebinding attack applied to an MCP transport, and it requires no direct compromise of the MCP server host itself, only that a victim visit a malicious page while the server is running and reachable.

Affected Systems

tiger-slack, MCP SDK (Node/TypeScript httpServerFactory); protocols: MCP

Detection Signatures

• Log requests to MCP HTTP server with unexpected or mismatched Host headers
• Monitor for repeated DNS resolution changes (rebinding) targeting domains resolving to loopback/private IPs shortly after initial resolution to public IPs
• Alert on MCP server receiving requests from Origin/Referer headers not matching expected client applications
• Check httpServerFactory invocation for missing or disabled dnsRebindingProtection / allowedHosts configuration option

Remediation Steps

1. 1

   Enable host allow-list / DNS-rebinding protection

   Explicitly set the DNS-rebinding-protection option when calling httpServerFactory in mcp/src/httpServer.ts, restricting accepted Host headers to known, expected values (e.g., localhost, 127.0.0.1, or explicit configured hostnames).

2. 2

   Update to patched version

   Upgrade tiger-slack to the commit/version that includes both the dependency update and the explicit allow-list configuration; note that the dependency bump alone does not remediate the issue.

3. 3

   Bind to loopback only where possible

   If the MCP server does not need network-wide exposure, bind it strictly to 127.0.0.1 and require authenticated local access to reduce exposure to browser-based rebinding attacks.

4. 4

   Add Origin/Host validation middleware

   Independently of SDK-provided protections, implement server-side validation that rejects requests with unexpected Host or Origin headers as defense in depth.

5. 5

   Audit other MCP server deployments

   Review any other locally-hosted MCP servers built on the same SDK for similarly missing allow-list configuration, since the vulnerability pattern (helper called without protection flag) may recur across services.