obsidian-tc EUVD-2026-97733

Exploitation requires the target to be running obsidian-tc (prior to 1.3.1) with the Streamable HTTP transport enabled and bound to loopback under the documented auth.mode 'none' configuration; in that mode requests receive full wildcard vault scopes. The attack further requires victim user interaction (UI:R): the user must visit an attacker-controlled web page while the server is running, so the malicious page's JavaScript can POST cross-origin to http://127.0.0.1:<port>/mcp. Limiting factors: it does NOT affect server-to-server MCP clients (which send no Origin header), it does NOT apply when auth is configured to anything other than 'none', and in 1.3.1+ the default enableDnsRebindingProtection blocks disallowed Host/Origin values. Deployments that set auth, restrict allowedHosts/allowedOrigins, or do not expose the HTTP transport to browser contexts are not exploitable.

This is a genuine, well-characterized security issue but its real-world priority is tempered by deployment footprint and preconditions rather than by signal conflict. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8) is internally consistent with the description: a remote, unauthenticated web page (PR:N) triggers the flaw only after a victim with the vulnerable server running visits attacker-controlled content (UI:R), yielding full read/write/delete access to the Obsidian vault (C:H/I:H/A:H). CWE-346 (Origin Validation Error) and the vendor commit (THE-271) confirm the root cause: the Streamable-HTTP transport validated neither Host nor Origin and had no DNS-rebinding protection. No EPSS score, CISA KEV listing, or standalone public exploit was provided; exploitation status is therefore 'no public exploit identified at time of analysis.' Note the fix commit does include a regression test that demonstrates the cross-origin attack (a 403-expecting test POSTing Origin: http://evil.example), so a working attack recipe is effectively public even though no weaponized exploit is cited. The one notable caveat: exploitation is gated on a specific deployment mode - the documented loopback configuration with auth.mode set to 'none' - so the AC:L / PR:N rating reflects a default-but-optional configuration rather than a flaw present in every install. This is a real priority for anyone actually running obsidian-tc with the HTTP transport in that mode, but the narrow, niche product footprint limits aggregate exposure.

A user runs obsidian-tc with the Streamable HTTP transport bound to loopback under auth.mode 'none' (the documented local default) and then browses to a malicious or compromised web page. JavaScript on that page issues a cross-origin POST to http://127.0.0.1:<port>/mcp, which the server accepts because it never checks Host or Origin, granting the page full wildcard-scope access to read, modify, and delete the victim's vault. The vendor's own fix includes a test reproducing this cross-origin drive-by, so an attack recipe is publicly available even though no packaged exploit is cited.