obsidian-tc GHSA-pqh8-4pj7-32xx: HTTP transport allows drive-by vault takeover via DNS rebinding/Origin spoofing (CVE-2026-77363)

What happened

A GitHub Security Advisory (GHSA-pqh8-4pj7-32xx, CVE-2026-77363, CVSS 9.6) discloses that the npm package obsidian-tc shipped its Streamable HTTP transport without enableDnsRebindingProtection, allowedHosts, or allowedOrigins, and performed no Origin-header validation at all. According to the advisory, combined with the documented default of auth.mode: "none" on loopback, a malicious web page visited by a victim could issue a POST http://127.0.0.1/mcp request and be granted the http-local caller identity with ["*"] scopes — full read/write access to the vault. The issue is fixed in version 1.3.1, which adds DNS-rebinding protection and allowed-hosts/origins checks and returns HTTP 403 on an invalid Origin, per the MCP 2025-11-25 spec. Exploit status is listed as PoC-public.

Why it matters

This is a classic drive-by/CSRF-style attack against a localhost-bound service: no attacker network position or user interaction beyond visiting a webpage is required for the exploit chain described in the advisory. Any installation running the HTTP transport with the no-auth loopback default is affected, and the impact is a full compromise of vault contents (read and write) — not a partial information leak. Because the vulnerable configuration is described as the documented default, exposure may be wider than installs that deliberately opted into weaker auth.

What defenders should do now

• Inventory any hosts running obsidian-tc and check the installed version; upgrade to >= 1.3.1.
• Where upgrading isn't immediately possible, apply the advisory's workarounds: avoid auth.mode: "none" on the HTTP transport, require JWT auth, and if the service must be reachable beyond loopback, front it with a proxy that enforces Origin validation.
• Hunt for anomalous local requests to the MCP endpoint (e.g. POST to 127.0.0.1/mcp or the service's bound port) originating from browser processes rather than the expected client, and for unexpected Origin headers in transport logs if logging is available.
• Review browser history/EDR telemetry on affected hosts for visits to untrusted pages around the time of any suspicious local vault access, since the described attack path relies on a victim loading attacker-controlled web content.

Developing intel

This analysis is based solely on the GHSA text as published; attribution, in-the-wild exploitation, and victim scope beyond what's stated are not confirmed. This is net-new, same-day intel — check the original advisory for updates: GHSA-pqh8-4pj7-32xx.