EUVD-2026-97737Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain any valid JWT for the HTTP edge
-
ExploitCall a vault tool with input.vault set to another vault's id
-
ExecutionDispatch runs tool against the unbound vault (no binding check)
-
ImpactRead, write, or delete the victim vault's contents
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires an obsidian-tc server running the HTTP transport with MORE THAN ONE vault configured, and the attacker must hold a valid JWT accepted by that HTTP edge (PR:L). The flaw is triggered only when a tool call includes a 'vault' argument naming a different configured vault - the ~90 vault tools resolve that caller-supplied id against any vault under the single global folder ACL. LIMITING FACTORS: the trusted stdio transport is entirely unaffected; single-vault deployments have no other vault to pivot to; and a valid token is mandatory (no anonymous access). Prior to 1.3.1 the JWT carried no vault claim, so any issued token could reach every vault. |
| Impact | This is a CWE-639 authorization-bypass (IDOR-style cross-tenant access) rated CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The vector is network-exploitable with low complexity, no user interaction, and a scope change reflecting access to resources outside the token's authorization boundary. Critically, PR:L confirms the attacker must already hold a valid low-privilege JWT - this is not unauthenticated. The high CVSS should be tempered by three real-world factors drawn from the source evidence: (1) exploitation only affects the HTTP transport in multi-vault deployments - the trusted stdio transport and single-vault setups are unaffected per the vendor CHANGELOG; (2) the affected product (obsidian-tc) is an obscure, recently published open-source MCP server with a very small deployment footprint; (3) no EPSS score was provided, there is no CISA KEV listing, and no public exploit was identified - the only code evidence is the vendor's own fix commit and its regression test, not a weaponized POC. Net: a genuinely severe authorization flaw for the narrow population running multi-vault HTTP obsidian-tc with shared tokens, but low aggregate real-world risk given the niche product and the valid-token prerequisite. No EPSS/KEV data was supplied, so exploitation-probability signals could not be cross-referenced against the CVSS score. |
| Exploit ScenarioDerived | An attacker possessing any valid JWT for a multi-vault obsidian-tc HTTP deployment issues a normal tool call but sets the input.vault argument to a different configured vault's id. Because dispatch never compares that value against the token's binding and the folder ACL is a single global instance, the call executes against the other vault, letting the attacker read, write, or delete its notes. No public POC exists; the only available code is the vendor's v1.3.1 fix commit and its accompanying cross-vault-binding regression test. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Improper authorization in obsidian-tc prior to 1.3.1 lets any holder of a valid JWT reach beyond its own vault and read, write, or delete the contents of every other configured vault on the same HTTP server. The flaw affects CWE-639-style trust in a caller-controlled key: tool dispatch never compares the caller-supplied input.vault value against the vault bound to the caller, the JWT carries no vault claim, and the folder ACL is a single global instance, so roughly 90 vault-scoped tools resolve an attacker-named vault id under that shared ACL. Exploitation requires the HTTP transport with more than one vault configured and a valid token (authenticated, PR:L); the trusted stdio transport is unaffected and single-vault deployments have no second vault to pivot to, but cross-tenant confidentiality, integrity, and availability are all fully compromised when those conditions hold - no public exploit code has been identified at time of analysis.
RemediationAI
Vendor-released patch: obsidian-tc 1.3.1 (https://github.com/The-40-Thieves/obsidian-tc/releases/tag/v1.3.1), delivered via commit 38b4992e87dc2715564236e1a42d005ab05a0194 and pull request 72, per advisory GHSA-84c9-qqpq-2pq5. Upgrade every obsidian-tc instance that exposes the HTTP transport with more than one configured vault; after upgrading, multi-vault HTTP deployments must mint one token per vault carrying the new 'vault' claim, and tokens issued without that claim are silently confined to the server's default vault (a behavior change that can break existing multi-vault integrations until tokens are reissued). Where upgrading immediately is not possible, the highest-value compensating control is to eliminate the cross-vault reach rather than to filter requests: run a separate single-vault obsidian-tc HTTP process per vault, or restrict the HTTP transport to one configured vault, so no second vault exists for the attacker-controlled 'vault' argument to name. Alternatively, move affected clients to the trusted stdio transport, accepting that this trades away the network-exposed deployment model and must be limited to a local operator you fully trust. Because a valid JWT is mandatory, reducing the blast radius further means tightening token issuance and rotation and limiting who can obtain a token to the vault they legitimately need, plus network-level restriction of the HTTP edge (allowlist the agent hosts, terminate auth at a proxy) - note these are partial mitigations only, since any token that is still accepted retains full read/write/delete reach across configured vaults until 1.3.1 is applied.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
obsidian-tc is a governed, agent-ready Model Context Protocol (MCP) server that exposes Obsidian vault contents to autonomous or LLM-driven clients through tools and resources. Its dispatcher (packages/server/src/mcp/registry.ts) routes calls from roughly 90 vault tools that accept a caller-supplied 'vault' argument, and that argument was validated only for existence against every configured vault, not against the identity of the caller. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the security decision keyed on an attacker-influenceable parameter. Two supporting design gaps made the bypass trivial - the JWT verification path (packages/server/src/auth/jwt.ts) produced no 'vault' claim, so an HTTP token carried no tenant binding at all, and the folder access-control list is a single global instance shared across all vaults rather than scoped per vault. The resources/read path already enforced a vault-match invariant, but the tool dispatch path did not, leaving the more powerful read/write/delete tool surface unguarded. Version 1.3.1 closes the gap by adding an optional 'vault' claim to JwtIdentity, propagating it through the HTTP edge (packages/server/src/transports/http.ts) into the caller context as vaultId plus a new vaultBound flag, and having registry.dispatch throw a 'forbidden' ObsidianTcError when a vault-bound caller's tool argument names any vault other than its bound one. Callers without a vault claim are confined to the server's default vault, and the trusted stdio context leaves vaultBound unset so a local operator retains intentional multi-vault access.
Know when Obsidian Tc gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Network-reachable HTTP edge (AV:N); a valid low-privilege token is required (PR:L); crossing into another vault's resources is a scope change (S:C) with full read/write/delete impact (C/I/A:H).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, tool dispatch does not compare the caller-controlled input.vault value with the vault bound to the caller, the JSON Web Token (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. Version 1.3.1 fixes the vulnerability by binding tokens and request context to a vault and rejecting mismatched input.vault values before scope checks.
Technical POC Analysis
The defect is CWE-639 Authorization Bypass Through User-Controlled Key, with the advisory also listing CWE-863 Incorrect Authorization.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
obsidian-tc, a server that exposes Obsidian vaults as tools over HTTP, fails to tie an authenticated caller to a specific vault, so any user holding a valid token can name another tenant's vault and read, modify, or delete its entire contents. Because the flaw affects only HTTP-exposed deployments hosting more than one vault, it converts an ordinary authenticated account into a cross-tenant data breach and destruction capability that undermines confidentiality, integrity, and availability for every customer hosted on the same server. Leadership should treat this as a multi-tenant trust-boundary failure requiring immediate isolation of affected deployments; no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis.
No vendor-released patch identified at time of analysis; interim mitigations are configuration and identity based. Disable the HTTP transport and operate obsidian-tc over the unaffected stdio transport, or restrict affected servers to a single vault so no second vault exists to pivot to. Rotate JWT signing keys and revoke existing tokens to invalidate any credentials already held, restrict HTTP network reachability to trusted clients, and monitor or alert on tool invocations whose vault parameter does not match the caller's bound vault. Note the flaw is reachable only by an authenticated principal (PR:L), so tightening token issuance and account lifecycle reduces exposure while awaiting a fixed build; upgrading to obsidian-tc 1.3.1 or later remains the durable remediation once available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Obsidian Tc
View allCross-origin requests to the obsidian-tc Model Context Protocol HTTP transport let any web page a victim visits read fro
obsidian-tc versions prior to 1.3.1 fail to enforce folder access controls on direct file requests, allowing an authenti
Read access-control bypass in obsidian-tc before version 1.3.1 allows an authenticated MCP client to read files inside a
Information disclosure in obsidian-tc (versions prior to 1.3.1) allows an authenticated caller of the MCP server to infe
Exploit-DB