What happened
In obsidian-tc, tool dispatch does not verify that the caller's input.vault matches the vault bound to the caller, the JWT has no vault claim, and the folder access-control list is shared globally. Any valid token can therefore select another configured vault and read, write, or delete its contents through affected tools. Combined with the sibling DNS-rebinding flaw in the documented loopback/no-auth mode, the vault data a connected AI agent can reach is not bounded per-caller.
Why it matters
MCP servers are the filesystem/hands of AI agents. A multi-tenant IDOR here means an agent holding any token — or, in the recommended no-auth loopback config, any local webpage via DNS rebinding — can silently read and destroy a different Obsidian vault's notes, embeddings, and plugin configuration (see also CVE-2026-77363/77364 for the same product).
Attack vector
The MCP tool dispatch never compares the caller-controlled input.vault value with the vault bound to the caller; the JWT carries no vault claim and the folder ACL is global. A valid token for one vault is sent a request naming another vault, and affected reads/writes/deletes operate on the target vault's files.
Affected systems
obsidian-tc (The-40-Thieves) < 1.3.1
Mitigation
Upgrade to obsidian-tc 1.3.1 (commit 38b4992e87dc..., PR #72). The fix binds tokens and request context to a vault and rejects mismatched input.vault before scope checks.