obsidian-tc MCP Server: Critical Vault Isolation Bypass Lets Any Token Read/Write/Delete Any Configured Vault (CVE-2026-77366)

What happened

A GitHub Security Advisory (GHSA-84c9-qqpq-2pq5, CVE-2026-77366, CVSS 9.9) discloses that the npm package obsidian-tc failed to validate caller-supplied vault parameters against the caller's bound vault context. According to the advisory, tool dispatch never checked input.vault against ctx.vaultId, the folder ACL was implemented as a single global instance, and the JWT carried no vault claim. The advisory states this affected roughly 90 tool sites, with only the resources/read surface already guarding against it. The result: any valid token could read, write, or delete any configured vault, breaking multi-tenant isolation entirely. A public PoC reportedly exists.

Why it matters

obsidian-tc appears to be an MCP-style tool server that multiplexes access to multiple Obsidian vaults behind a shared process. If a deployment hosts multiple tenants or customers on one server instance, this flaw means authentication (having any valid token) was sufficient but authorization (scoping to your own vault) was not enforced — a classic broken object-level authorization (BOLA/IDOR-class) issue, but with full read/write/delete impact rather than read-only exposure. Any organization running a shared, multi-vault deployment of this package should treat prior access-control assumptions as invalid until patched.

What defenders should watch for now

• Inventory whether obsidian-tc is deployed anywhere in your environment, and whether a single server process serves more than one vault/tenant.
• Check the installed version; per the advisory, the fix lands in 1.3.1 (the 1.3.0 tag never published to npm), so confirm you are on >= 1.3.1, not just past 1.3.0.
• Until patched, the advisory's workaround is to run a single vault per server process or isolate each tenant on its own process/credential — review current deployment topology against this.
• From a hunting perspective, review logs for tool-dispatch calls where the vault parameter in the request does not match the vault bound to the caller's token/session — this is the exact condition the vulnerability exploited, though logging detail will depend on your deployment's instrumentation.
• Audit any tokens that may have been used across vault boundaries during the vulnerable window, since the advisory indicates this was exploitable for data read, modification, or deletion.

Developing intel

This is a same-day advisory and details may evolve; this post reflects only what has been published so far. For authoritative details, patch guidance, and updates, see the original GitHub Security Advisory: GHSA-84c9-qqpq-2pq5.