GHSA-84c9-qqpq-2pq5: Critical severity npm/obsidian-tc vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/obsidian-tcto a version that resolves this vulnerability.Fixed in 1.3.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.3.1 - Compensating control
Run a single vault per server process, or isolate each tenant on a separate process and credential.
Event History
Frequently Asked Questions
Who is exposed to cross-tenant access?
Deployments that configure multiple vaults in the same server process are exposed. Any holder of a valid token can target another configured vault by supplying its name in input.vault; resources/read was the exception because it already enforced a guard.
What access does an attacker need to exploit this?
The attacker needs any valid token. No additional user interaction is required, and the token does not need to include a claim for the vault being targeted.
What can an attacker do after exploiting the issue?
An attacker can read, write, or delete content in any configured vault through affected tool-dispatch surfaces. This defeats the intended isolation between tenants.
What should be done if an immediate upgrade is not possible?
Run only one vault per server process, or isolate each tenant into a separate process with separate credentials. This prevents a token for one tenant from being able to target another vault in the same process.
Which release contains the fix?
Upgrade npm/obsidian-tc to version 1.3.1 or later. Version 1.3.1 is the first published release containing the central check that input.vault matches the caller's bound vault.