CVE-2026-77363 in obsidian-tc
Summary
by MITRE • 10/12/2026
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, the Streamable HTTP transport does not validate the Host or Origin header or enable DNS-rebinding protection. When the documented loopback configuration uses auth.mode set to none, a malicious web page can send requests to the local MCP endpoint and receive unrestricted vault access through the http-local caller. Version 1.3.1 fixes the vulnerability by enabling host, origin, and DNS-rebinding validation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The obsidian-tc server serves as a governed interface for Obsidian vaults via the Model Context Protocol, allowing external agents to interact with local documentation repositories. A critical security deficiency existed in versions prior to 1.3.1 regarding its Streamable HTTP transport mechanism. Specifically, the application failed to validate the Host or Origin headers of incoming requests and lacked DNS rebinding protection measures. This oversight created a significant attack surface for cross-origin attacks when the server was configured with authentication disabled by setting auth.mode to none. In this configuration, which is often used in local development or trusted loopback scenarios, the service relied on implicit trust assumptions that were not technically enforced at the protocol level.
The absence of header validation allows malicious web pages hosted on remote domains to send HTTP requests directly to the local MCP endpoint running on localhost. Because the server did not check if the request originated from a legitimate source or matched expected host identifiers, it treated these external requests as valid internal calls. This flaw effectively bypasses standard browser same-origin policies that typically restrict how scripts in one origin can interact with resources in another. Consequently, an attacker could craft a malicious webpage designed to exploit this trust boundary, sending commands to the obsidian-tc server and receiving unrestricted access to the user's Obsidian vault data through the http-local caller mechanism.
The operational impact of this vulnerability is severe for users who run the service without authentication enabled. An exploited instance allows remote attackers to read sensitive notes, potentially exfiltrate private information stored in the vault, or modify existing content depending on the specific permissions granted by the MCP implementation. This scenario aligns with CWE-346, which describes the failure of an application to perform proper origin validation for cross-origin requests. Furthermore, it relates to CWE-918 regarding Server-Side Request Forgery (SSRF) variants where client-side controls are insufficient without server-side enforcement. The lack of DNS rebinding protection further exacerbates the risk by allowing attackers to resolve malicious domains to localhost addresses during runtime, bypassing initial static IP checks if any were present in earlier iterations or related configurations.
To mitigate this vulnerability and secure future deployments, it is imperative that users upgrade to version 1.3.1 or later of obsidian-tc. This release explicitly introduces validation for the Host and Origin headers along with robust DNS rebinding protection mechanisms. For environments where authentication cannot be enabled due to specific workflow requirements, administrators should ensure these header validations are strictly enforced at the network perimeter using reverse proxies such as Nginx or Apache. These proxies can inspect incoming requests before they reach the application layer, dropping any traffic that does not originate from trusted sources. Additionally, adhering to security best practices suggests always enabling authentication modes whenever possible to add a secondary layer of defense against unauthorized access attempts.