CVE-2026-81099 in tiger-slack
Summary
by MITRE • 08/27/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in tiger-slack represents a critical misconfiguration of HTTP transport security mechanisms within its Model Context Protocol implementation. Specifically, the MCP HTTP server was initialized without enabling host allow-listing features provided by the underlying software development kit. This oversight occurred because the codebase invoked the shared httpServerFactory helper function but failed to pass or configure the specific option required for DNS rebinding protection. In secure web application architecture, such a configuration is essential to restrict incoming requests to trusted origins and prevent unauthorized entities from exploiting the server's local accessibility. By omitting this parameter, the transport layer effectively accepted HTTP requests regardless of the Host header value specified by the client, thereby removing a fundamental defense against host-based attacks.
The operational impact of this flaw allows for DNS rebinding attacks where an attacker can manipulate browser behavior to bypass same-origin policies. An adversary could craft a malicious webpage that directs its domain name resolution to point at the local IP address and port where the Slack MCP server is bound. Because the server does not validate the Host header against a whitelist, it processes these requests as legitimate interactions with the locally reachable service. This enables an attacker in control of the browser environment to drive actions on the vulnerable application through standard web protocols, potentially leading to unauthorized data access or execution of privileged operations within the context of the Slack MCP server. The severity is heightened by the fact that this vulnerability persists across all versions prior to the specific commit that introduced the fix, as no intermediate releases were published to mitigate the issue earlier.
The resolution involves explicitly passing the DNS-rebinding-protection option during the initialization of the HTTP server instance alongside a necessary dependency update. It is important to note that the dependency update alone was insufficient to close this vulnerability; the explicit configuration change was required to enforce host validation logic. This distinction highlights the importance of verifying that library updates do not inadvertently disable security features or rely on default behaviors that may be insecure in production environments. The affected boundary for remediation purposes extends from the beginning of the project history up to, but excluding, the commit where this explicit configuration was added and validated.
From a standards perspective, this vulnerability aligns with CWE-15: External Control of System or Configuration Setting, as the security control was improperly configured due to missing parameters. It also maps to MITRE ATT&CK techniques related to DNS Rebinding, which exploit browser trust models by changing domain resolution after initial page load to access internal resources. To mitigate similar risks in future developments, developers must ensure that all security-related configuration options are explicitly defined and validated during service initialization rather than relying on implicit defaults. Regular audits of HTTP server configurations against industry best practices for host header validation will help prevent such misconfigurations from reaching production environments.