Threat database

obsidian-tc versions from 1.0.1 up to but not including 1.31.4 have an incomplete cleanup vulnerability where certain entity lifecycle operations can overwrite or corrupt vault notes due to inconsistent handling of note ownership and filesystem failures. This can result in unauthorized overwriting of note bodies and inconsistencies between the SQLite memory graph and notes on disk. The issue is fixed in version 1.31.4.

obsidian-tc versions from 1.13.0 up to but not including 1.31.4 contain an improper authorization vulnerability. This flaw allows a client to bypass human approval for certain destructive vault operations when using Streamable HTTP deployment with auth.jwtSecret configured and a client supporting elicitation.form. The server incorrectly trusts a previously minted requestState as proof of approval, enabling execution of dispatch-gated destructive actions without explicit human consent. The issue is fixed in version 1.31.4.

### Impact ACL checks ran on the lexical vault-relative path while containment used the realpath. An in-vault symlink placed under an allowed glob, whose realpath resolved into a denied folder, passed the read ACL — an intra-vault read-ACL-scope bypass. It requires an out-of-band-planted symlink (no MCP tool creates one) and is not a vault-root escape. ### Patches Fixed in **1.3.1**. Upgrade to `>= 1.3.1`. ACL enforcement now derives the realpath vault-relative path and feeds a single unified predicate at every site. ### Workarounds Do not permit untrusted symlinks inside the vault.

obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, bridge tools do not consistently apply the read access-control list (ACL) to every returned field. The tasks_filter tool exposes group counts derived from denied notes, makemd_query passes unfiltered sibling result fields through, and list_templates exposes template paths and parsed user-function bodies without a read-whitelist check. An authenticated caller can consequently infer or read data from notes outside the caller's read ACL. Version 1.3.1 fixes the vulnerability by filtering path-attributable fields and applying the read whitelist to list_templates.

### Impact Tool dispatch did not check the caller-supplied `input.vault` against the caller's bound vault (`ctx.vaultId`); the folder ACL was a single global instance and the JWT carried no vault claim. As a result, **any valid token could read, write, or delete any configured vault** by passing `input.vault`, defeating multi-tenant isolation across ~90 tool sites. (`resources/read` was the only surface that already guarded this.) ### Patches Fixed in **1.3.1** (the fix was developed on the `v1.3.0` tag, which never published to npm; 1.3.1 is the first published release with the fix). Upgrade to `>= 1.3.1`. ### Workarounds Run a single vault per server process, or isolate each tenant on a separate process/credential. ### Fix A central `input.vault === ctx.vaultId` guard was added in dispatch before the scope check.

### Impact With a default configuration, an undefined `readPaths`/`writePaths` meant allow-all, the `strictReadDefault` flag was inert, and the `.obsidian`/`.git`/`.trash` control directories were denied only during enumeration — not on the direct request path. A caller could read `.obsidian/plugins/*/data.json`, exfiltrating **plugin API keys and Obsidian Sync passwords** (live-reproduced), as well as any other in-vault file by path. ### Patches Fixed in **1.3.1**. Upgrade to `>= 1.3.1`. The default now denies `.obsidian`/`.git`/`.trash` on read/write/delete and honors `strictReadDefault` on the request path. ### Workarounds Set an explicit `readPaths`/`writePaths` whitelist that excludes the control directories.

CVE-2026-77363 is a high-severity vulnerability in obsidian-tc, a Model Context Protocol server for Obsidian vaults. Versions prior to 1.3.1 do not validate the Host or Origin HTTP headers and lack DNS-rebinding protection in the Streamable HTTP transport. When configured with auth.mode set to none in the documented loopback setup, this allows a malicious web page to send requests to the local MCP endpoint and gain unrestricted access to the vault via the http-local caller. Version 1.3.1 addresses this issue by enabling proper host, origin, and DNS-rebinding validation.