On this page (7 sections)
obsidian-tc, an npm package that runs a Model Context Protocol (MCP) server for Obsidian vaults, has a critical authorization flaw tracked as CVE-2026-77366. According to the GitHub advisory, any valid token can select another configured vault and read, write or delete its contents. Versions before 1.3.1 are affected.
If you host obsidian-tc for more than one user, team or client, this is the kind of bug that breaks the promise of separation between them. The advisory's own workarounds focus on keeping vaults and tenants apart, so multi-vault deployments are the ones to check first.
What happened
The GitHub advisory describes a missing check in how obsidian-tc dispatches tool calls. It shows the advisory was published in the The-40-Thieves/obsidian-tc repository on Jul 3, 2026, published by the National Vulnerability Database on Oct 12, 2026, and published to and reviewed in the GitHub Advisory Database on Oct 23, 2026. The credited finder is listed as suavecito585.
So far this story is covered by one publisher, the advisory itself, plus the linked fix pull request and release notes. We have not seen independent confirmation or any report of attacks in the wild.
Technical details: a missing vault check
An MCP server exposes tools that an AI agent or client can call. In obsidian-tc, each caller authenticates with a JSON Web Token (JWT) and is bound to a vault. The advisory says three things went wrong together:
- Tool dispatch did not compare the caller-supplied input.vault value with the vault bound to the caller (ctx.vaultId).
- The JWT carried no vault claim, so the token itself said nothing about which vault it was meant for.
- The folder access-control list (ACL) was a single global instance rather than separated per vault.
The result is an authorization bypass through a user-controlled key (CWE-639, with CWE-863 for the incorrect check). The caller controls a field that picks the data, and the server trusts it. By passing a different input.vault, a valid token could read, write or delete any configured vault. The advisory says this defeated multi-tenant isolation across roughly 90 tool sites, and that resources/read was the only surface that already guarded against it.
The CVSS vector reflects this: network reachable, low complexity, low privileges (a valid token), no user interaction, and a changed scope with high impact on confidentiality, integrity and availability. In plain terms, one low-privilege credential becomes access to other vaults.
Who is affected
Based on the advisory, you are realistically exposed if these apply:
- You run obsidian-tc at a version below 1.3.1.
- The server has more than one vault configured.
- Different people, teams, agents or customers hold tokens for different vaults.
- The server is reachable by those token holders over a network.
The advisory's suggested workarounds are to run a single vault per server process, or to isolate each tenant on a separate process or credential. We treat those as mitigations offered by the advisory, not as proof that a single-vault server is safe. Since any valid token is enough to trigger the flaw on an affected version, a stolen or over-shared token deserves attention too.
How to check your exposure
First find out which version you have installed. This read-only command, run in your project directory, lists the installed obsidian-tc version. Anything below 1.3.1 is affected.
npm ls obsidian-tcIf you installed it globally, this read-only command shows the global version instead:
npm ls -g obsidian-tcThen review your server configuration and count how many vaults it serves. More than one vault together with a version below 1.3.1 means you should treat the deployment as exposed.
What to do now
The fix is to upgrade. The maintainers added a central check that input.vault must equal ctx.vaultId in dispatch, before the scope check, and tokens and request context are now bound to a vault. Mismatched values are rejected.
This command, run in the project directory, installs exactly version 1.3.1, the first fixed release. If you prefer to accept later compatible releases, you can use a version range instead, but pinning makes the fix easy to verify.
npm install obsidian-tc@1.3.1After the upgrade, run the version check again and confirm it reports 1.3.1 or higher, then restart the service using your usual process manager.
0 of 8 done
Detection and monitoring
The advisory does not describe log signatures for abuse, so we cannot give a confirmed indicator. The following are the author's suggestions for reviewing your own deployment, not indicators from the advisory:
- Tool calls where the requested vault differs from the vault the token was issued for, if your logging records both.
- Reads, writes or deletes against vaults that a given client has never used before.
- Unexpected edits, new notes or missing notes in vaults that should be quiet.
If your logs do not capture the vault identifier on each call, consider adding that logging after you patch so future reviews are possible. Keep an eye on the project advisory in case maintainers add details.
For the wider server around it, regular checks of your public endpoints help catch drift. A free security headers check and certificate and uptime monitoring through Webforta Monitor are reasonable basics for any service you expose, though they do not test for this specific flaw.
Timeline
| Date | Event |
|---|---|
| Jul 3, 2026 | Advisory published in The-40-Thieves/obsidian-tc |
| Oct 12, 2026 | Published by the National Vulnerability Database |
| Oct 23, 2026 | Published to and reviewed in the GitHub Advisory Database; last updated |
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.