Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-12T18:17:23.513Z",
  "pubdate": "2026-10-12T18:17:23.513Z",
  "executiveSummary": "The obsidian-tc Model Context Protocol (MCP) server prior to version 1.3.1 contains a critical security vulnerability related to the improper validation of HTTP headers. Due to a failure to validate Host and Origin headers, alongside a lack of DNS-rebinding protection within the Streamable HTTP transport, the server is susceptible to unauthorized cross-origin requests.\nThis vulnerability is particularly severe when the server is configured with auth.mode set to 'none' in a loopback environment. An attacker can leverage a malicious website visited by a user to issue authenticated requests to the local MCP endpoint. This allows for unauthorized interaction with the user's Obsidian vault, potentially leading to the extraction of sensitive information or the execution of unauthorized agent operations.\nThe attack is characterized as a Cross-Site Request Forgery (CSRF) style exploit facilitated by DNS-rebinding. It requires the victim to browse to a malicious site while the obsidian-tc server is running with weak authentication controls. The impact includes full read and write access to the user's local vault data, depending on the capabilities granted to the MCP server. Users are urged to upgrade to version 1.3.1 immediately to implement essential host, origin, and DNS-rebinding validation checks.",
  "technicalDetails": "The root cause of this vulnerability lies within the Streamable HTTP transport mechanism of the obsidian-tc MCP server, which fails to enforce strict security policies regarding the provenance of incoming HTTP requests. Specifically, the implementation lacks server-side verification of the 'Host' and 'Origin' headers, which are primary defense mechanisms against Cross-Site Request Forgery (CSRF) and DNS-rebinding attacks in local web services.\nIn a typical loopback deployment, the obsidian-tc server listens on a local port (e.g., 127.0.0.1). When 'auth.mode' is set to 'none', the service effectively treats any request originating from the local machine as trusted. An attacker can exploit this by directing a victim's browser to a malicious web page. Through DNS-rebinding—a technique where a domain name is resolved to an attacker-controlled IP address and subsequently 'rebinding' to a local loopback address (127.0.0.1)—the malicious script can bypass browser-based Same-Origin Policy (SOP) restrictions.\nBecause the obsidian-tc server does not validate the Host header, it will accept these re-bound requests as legitimate traffic directed at the intended local service. Once the browser context is tricked into communicating with the local port, the malicious script can dispatch arbitrary JSON-RPC requests to the MCP endpoint. Since the authentication mode is disabled, the server processes these commands without requiring credentials or session tokens.\nThe attack flow follows these steps: 1) The user navigates to an attacker-controlled website. 2) The attacker's script initiates a DNS-rebinding process, effectively resolving the malicious domain to 127.0.0.1. 3) The script sends unauthorized HTTP requests to the obsidian-tc server port. 4) The server processes the requests, ignoring the discrepancy in Host/Origin headers due to the lack of validation logic. 5) The server executes the instructions contained in the request, granting the attacker access to the vault. This post-exploitation impact allows for data exfiltration, modification of vault content, or the abuse of agentic tools authorized within the MCP scope, effectively compromising the privacy and integrity of the user's personal knowledge base."
}