CVE-2026-77361 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, read access-control list (ACL) checks use a lexical vault-relative path while containment checks use the resolved path. An in-vault symlink under an allowed glob that resolves into a denied folder can therefore bypass the read ACL and expose files in the denied folder. Exploitation requires an out-of-band-planted symlink and does not permit an escape from the vault root. Version 1.3.1 fixes the vulnerability by applying ACL checks to the resolved vault-relative path.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The obsidian-tc server, designed as a governed agent-ready Model Context Protocol implementation for Obsidian vaults, contains a critical access control flaw in versions prior to 1.3.1 that allows unauthorized file disclosure through symlink manipulation. This vulnerability stems from an inconsistency in how the application validates user permissions against filesystem paths. Specifically, the read access-control list checks are performed using the lexical vault-relative path provided by the client or requestor, while containment checks that verify whether a file resides within the allowed vault boundaries utilize the resolved physical path after symbolic links have been dereferenced. This discrepancy creates a logic gap where an attacker can craft requests that appear to target files within permitted directories based on their textual representation, but actually resolve to locations outside those permissions due to underlying symlink redirections.
The technical mechanism of this exploitation relies on the creation of out-of-band symlinks planted by an adversary with write access to specific parts of the vault or through prior compromise. An attacker can establish a symbolic link within a directory that is explicitly allowed by the read ACL, such as a public notes folder. This symlink points to a file located in a different part of the vault that has been denied access via the same ACL policy. When an agent or user requests this file using its lexical path through the allowed glob pattern, the system validates the request against the visible directory structure and grants permission because the path appears compliant. However, when the server attempts to read the actual content, it resolves the symlink to the physical location of the target file, which resides in a restricted area. Because the containment check uses this resolved path but the ACL check used the original lexical path, the security boundary is effectively bypassed without triggering an access denied error for the initial request validation phase.
The operational impact of this vulnerability is significant as it enables information disclosure across logical boundaries defined by the vault's permission model. Sensitive documents, configuration files, or private notes that were intended to be inaccessible to certain users or agents can be read if they are referenced via a symlink in an accessible location. This undermines the integrity and confidentiality guarantees provided by the ACL system. It is important to note that this vulnerability does not permit escape from the vault root itself; the attacker cannot access files outside of the designated Obsidian vault directory structure on the host filesystem. The attack vector requires prior ability to plant symlinks within the vault, meaning it typically represents a privilege escalation or lateral movement risk rather than an initial entry point for external attackers without some level of existing write access or code execution capability within the vault environment.
To mitigate this vulnerability and align with industry best practices such as CWE-22 Improper Limitation of a Pathname to a Restricted Directory, administrators must upgrade obsidian-tc to version 1.3.1 or later. The fix addresses the root cause by ensuring that access-control list checks are applied consistently against the resolved vault-relative path rather than the lexical input. This ensures that both containment and permission validation operate on the same physical reality of the file system, preventing symlink-based bypasses. Additionally, organizations should enforce strict controls over who can create symbolic links within their Obsidian vaults to reduce the attack surface for this type of logic flaw exploitation. Monitoring for unusual patterns in path resolution or unexpected access attempts to restricted directories can also aid in detecting potential abuse while patching efforts are underway. This incident highlights the importance of consistent path handling in security-critical applications and serves as a reminder that logical flaws often pose greater risks than simple input validation errors when dealing with complex file system interactions.