CVE-2026-77361: obsidian-tc symlink path mismatch bypasses read ACL restrictions
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
obsidian-tcto a version that resolves this vulnerability.Fixed in 1.3.1
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using obsidian-tc versions before 1.3.1 are exposed if their vault contains a symlink located under a read-allowed glob that resolves to a folder denied by the read ACL. The issue is limited to reading files within the vault root.
What must an attacker have to exploit it?
Exploitation requires a symlink to have been planted out of band. An attacker also needs the symlink to be placed under a path allowed by the read ACL while its resolved target is in a denied folder.
Does this allow access outside the Obsidian vault?
No. The containment check still prevents escape from the vault root; the bypass can expose files in denied folders inside that root.
What should be done if upgrading is not immediately possible?
Review the vault for symlinks, especially those beneath paths matched by allowed read globs, and remove or restrict symlinks that resolve into denied folders. This reduces the condition required for the ACL bypass.
How is the issue fixed?
Upgrade to version 1.3.1. This version applies read ACL checks to the resolved vault-relative path rather than the lexical path.