Upgrade Obsidian-TC to 1.3.1 to stop token-holders from deleting vault data via critical auth flaw

An attacker possessing a valid authentication token can access, modify, or delete contents within any configured vault in Obsidian-TC versions prior to 1.3.1. This capability exists because the software fails to verify that the requested vault matches the one authorized for the specific token holder. The flaw allows for complete data manipulation across vault boundaries, effectively breaking the intended isolation between separate data stores.

The National Vulnerability Database rates this vulnerability as critical with a CVSS score of 9.9. The flaw involves weaknesses identified as CWE-639 and CWE-863. An adversary does not need to break authentication; they only need a single valid token. Once authenticated, they can specify a different vault in their request and the server will process the command without checking if the token grants access to that specific target.

How the breach occurs

The core issue lies in how Obsidian-TC handles tool dispatch and access control. The system does not compare the vault value provided in the caller's input against the vault actually bound to the caller's session. Additionally, the JSON Web Token used for authentication lacks a specific vault claim, meaning it does not explicitly state which vault the user is allowed to access. Consequently, the folder access-control list is shared globally rather than being restricted per vault or per user session.

This design oversight means any valid token acts as a master key for all configured vaults. An attacker can simply select another configured vault in their request parameters. The server then allows read, write, or delete operations on those contents through affected tools, ignoring the intended security boundaries. This enables full data exfiltration or destruction without triggering standard access-denied errors.

Who is affected

The vulnerability affects users of The-40-Thieves obsidian-tc software running versions earlier than 1.3.1. Obsidian-TC is described as a governed, agent-ready Model Context Protocol server for Obsidian vaults. Any deployment using this software before the patch release is exposed to the risk of cross-vault data theft or manipulation. Organizations relying on this server for multiple vaults are particularly vulnerable, as the global access-control list fails to segregate data between them.

The fix was introduced in version 1.3.1. This update addresses the vulnerability by binding tokens and request context to a specific vault. It also adds a check to reject mismatched input.vault values before performing scope checks. Users must update to this version or later to restore proper vault isolation and prevent unauthorized access to data stores that should be protected from other authenticated users.

What to watch

Monitor official channels from The-40-Thieves for any follow-up disclosures regarding this vulnerability or related issues. Check your server logs for unusual access patterns, particularly requests that target vaults different from the user's primary assigned vault. Look for signs of data exfiltration or unexpected deletions across multiple vaults, which could indicate exploitation.

Verify that all instances of obsidian-tc in your environment are updated to version 1.3.1 or higher. Ensure that the update process completes successfully and that the new binding logic is active. If you cannot update immediately, consider restricting network access to the server to trusted sources only, although this does not mitigate the risk from compromised valid tokens.

What made it possible

This incident highlights the risks of improper authorization checks in multi-tenant systems. When applications fail to bind user sessions to specific resources, attackers can manipulate input parameters to access unauthorized data. Teams usually rely on tokens to establish identity, but if those tokens lack specific scope claims, they become too permissive.

Check whether your systems verify resource ownership at every request stage. Ensure that access controls are enforced server-side, not just client-side. Validate that input values match the authorized context before processing any commands. This prevents attackers from bypassing isolation boundaries by simply changing target identifiers in their requests.

What to do and how to stay safe: Obsidian-TC

• Update your Obsidian-TC server to version 1.3.1 or the latest available release immediately.
• Audit your server logs for any requests that accessed vaults inconsistent with the user's expected permissions.
• Review your authentication configuration to ensure tokens include specific scope or vault claims.
• Restrict network access to the server to reduce the attack surface while you verify the update.

Step-by-step guide: How Security Advisories Drive Patch Decisions and Reduce Risk

General security guidance from the Shell Bulletin newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVSS score for CVE-2026-77366?

The National Vulnerability Database rates the vulnerability as critical with a CVSS score of 9.9.

Which versions of Obsidian-TC are affected by this flaw?

All versions of The-40-Thieves obsidian-tc prior to 1.3.1 are affected by this vulnerability.

Does a fix exist for this vulnerability?

Yes, version 1.3.1 fixes the vulnerability by binding tokens to vaults and rejecting mismatched inputs.