CVE-2026-77362 in obsidian-tc
Summary
by MITRE • 10/13/2026
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, bridge tools do not consistently apply the read access-control list (ACL) to every returned field. The tasks_filter tool exposes group counts derived from denied notes, makemd_query passes unfiltered sibling result fields through, and list_templates exposes template paths and parsed user-function bodies without a read-whitelist check. An authenticated caller can consequently infer or read data from notes outside the caller's read ACL. Version 1.3.1 fixes the vulnerability by filtering path-attributable fields and applying the read whitelist to list_templates.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The obsidian-tc project serves as a governed, agent-ready Model Context Protocol server designed for Obsidian vaults, facilitating structured access to personal knowledge bases through automated agents. A significant security flaw was identified in versions prior to 1.3.1 regarding the enforcement of read access-control lists across various bridge tools within the system. The core issue stems from an inconsistent application of authorization checks, where certain API endpoints and tool functions failed to validate whether a caller had explicit permission to view specific data fields before returning them. This architectural oversight creates a bypass mechanism for access control policies that are otherwise enforced at higher levels or in other parts of the application logic.
The vulnerability manifests through multiple distinct pathways within the server's functionality, each exposing sensitive information due to insufficient filtering. The tasks_filter tool was found to expose group counts derived from notes that should have been denied based on the caller's read access-control list. By aggregating metadata such as task counts or grouping statistics, an attacker can infer the existence and potentially the nature of restricted content without directly viewing its body. Similarly, the makemd_query function passed unfiltered sibling result fields through to the client side, allowing for the retrieval of associated data linked to queried items even when direct access to those siblings was prohibited by policy. These mechanisms effectively undermine the principle of least privilege by leaking contextual information that should remain hidden from unauthorized users.
Furthermore, the list_templates tool presented a more direct vector for data exfiltration by exposing template paths and parsed user-function bodies without performing any read-whitelist checks. This oversight allows an authenticated caller to enumerate available templates and inspect their internal logic or embedded secrets, which may contain sensitive configuration details or proprietary algorithms not intended for public consumption within the vault structure. The combination of these flaws means that an attacker with valid authentication credentials can systematically reconstruct a map of restricted notes through metadata leakage and indirect data access, effectively bypassing the intended isolation boundaries established by the system's security model.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing restrictive policies on authorized users or contexts. The ability to infer denied information via side-channel metadata like group counts also touches upon aspects of CWE-209 Generation of Error Message Containing Sensitive Information, although the primary impact is unauthorized data disclosure rather than error leakage. In terms of tactical mapping, this behavior corresponds to ATT&CK technique T1530 Data from Cloud Storage Object or Directory, as it involves reading files and metadata from a storage system in violation of access policies. The exploitation relies on authenticated interaction with the API, placing it within the scope of lateral movement or data staging if an agent is compromised.
The operational impact of this vulnerability allows for the unauthorized inference and reading of data that falls outside the caller's designated read permissions. While direct content modification may not be possible depending on write ACLs, the ability to enumerate restricted resources and extract associated metadata compromises the confidentiality guarantees provided by the access control system. This can lead to privacy violations in personal knowledge management contexts where users expect strict separation between public and private notes. For organizations using this tool for enterprise knowledge bases, it could result in the exposure of confidential business information or intellectual property through indirect means such as template inspection or aggregate statistics analysis.
Version 1.3.1 addresses these issues by implementing rigorous filtering mechanisms for path-attributable fields and ensuring that the read whitelist is consistently applied to all endpoints, including list_templates. This fix enforces a uniform policy where every data retrieval operation undergoes an access control check before returning results. To mitigate risks in environments still running older versions, administrators should restrict network exposure of the obsidian-tc service to trusted internal networks only and ensure that agent identities are strictly scoped with minimal necessary permissions. Regular auditing of ACL configurations is recommended to verify that all tools adhere to the intended security model until an upgrade can be performed.