What happened
obsidian-tc's Streamable HTTP transport lacks Host/Origin header validation and DNS-rebinding protection. When the documented loopback configuration uses auth.mode=none, a malicious web page can issue cross-origin (or DNS-rebinding) requests to the local MCP endpoint and receive unrestricted vault access as the http-local caller — a browser-based alternative route to the vault-IDOR in the same product.
Why it matters
Combined with CVE-2026-77366, this gives a remote attacker a browser-only path (a mere visit to a crafted page) into a user's local Obsidian vault MCP server, and through it into vault file read/write/delete — the MCP equivalent of drive-by localhost access that the classic DNS-rebinding attacks against dev servers exploit.
Attack vector
The Streamable HTTP transport does not validate Host or Origin headers nor enable DNS-rebinding protection. In the documented loopback config with auth.mode=none, a malicious web page sends requests to the local MCP endpoint and obtains unrestricted vault access through the http-local caller.
Affected systems
obsidian-tc (The-40-Thieves) < 1.3.1 (Streamable HTTP transport)
Mitigation
Upgrade to obsidian-tc 1.3.1 (commit 6428bfe6fdfd43aa7b4b369be3aecd6a268fb928; PR #74), which enables host/origin/DNS-rebinding validation. Do not rely on auth.mode=none for sensitive vaults.