GHSA-c5xx-h28h-f682: Medium severity npm/obsidian-tc vulnerability
Impact ACL checks ran on the lexical vault-relative path while containment used the realpath. An in-vault symlink placed under an allowed glob, whose realpath resolved into a denied folder, passed the read ACL — an intra-vault read-ACL-scope bypass. It requires an out-of-band-planted symlink (no MCP tool creates one) and is not a vault-root escape.
Patches Fixed in 1.3.1. Upgrade to >= 1.3.1. ACL enforcement now derives the realpath vault-relative path and feeds a single unified predicate at every site.
Workarounds Do not permit untrusted symlinks inside the vault.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/obsidian-tcto a version that resolves this vulnerability.Fixed in 1.3.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.3.1 - Compensating control
Do not permit untrusted symlinks inside the vault.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments are exposed when their vault contains an untrusted symlink under an allowed glob whose target resolves to a folder denied by the read ACL. This is limited to bypassing read-ACL scope within the vault and is not a vault-root escape.
What must an attacker be able to do to exploit it?
An attacker needs an out-of-band-planted symlink in the vault. The MCP tools do not create such a symlink, so exploitation depends on another mechanism or party placing it there.
Are default deployments affected?
The issue depends on a vault configuration with read ACLs that distinguish allowed and denied paths, plus an untrusted symlink placed beneath an allowed glob. The provided information does not establish whether this condition exists in a default configuration.
What can be done if upgrading is not immediately possible?
Do not permit untrusted symlinks inside the vault. Upgrade obsidian-tc to version 1.3.1 or later when possible.