tiger-slack launched its MCP HTTP transport without enabling the host allow‑list that the SDK normally provides. The HTTP server was started by calling httpServerFactory and never set the DNS‑rebinding‑protection option, allowing requests to be accepted regardless of the Host header. Consequently, an attacker could host a page under a domain that a victim controls, configure that domain to resolve to the address the Tiger‑Slack server is bound to, and use the victim’s browser to remotely invoke the locally reachable Slack MCP server. This bypasses any network boundaries that rely on host validation and could let the attacker perform operations against the internal server, potentially leading to arbitrary code execution or data exfiltration. The weakness is a classic DNS rebinding flaw (CWE‑346).

Timescale's Tiger‑Slack application is affected for all commits preceding the fix found in pull request #146. No specific released version numbers are listed; the vulnerability exists in the code base before the applied dependency upgrade and configuration change. Any deployment of Tiger‑Slack that has not incorporated that commit remains susceptible.

The CVSS score of 7.6 indicates high severity. EPSS data is currently unavailable, so no quantified probability of exploitation can be given, but the lack of mitigation in the server configuration suggests it could be readily exploited via a user’s browser. The vulnerability is not listed in CISA’s KEV catalog, meaning no publicly known exploits have been observed, yet the nature of DNS rebinding is deterministic and could be leveraged in targeted attacks. The likely attack vector involves a malicious webpage that exploits the rebinding to redirect the victim’s traffic to the local MCP server, a path that requires only a visitor to load the page and no elevated privileges on the host.