Obsidian-TC allowed direct file requests for hidden credential-bearing vault paths

In the affected default configuration, unspecified readPaths and writePaths were treated as permission for all paths, while strictReadDefault was ineffective on direct file requests. Obsidian control folders, including .obsidian, .git and .trash, were omitted from listings but remained reachable by exact path. The maintainer reports reproduction of reads of .obsidian/plugins/*/data.json containing API credentials and sync secrets.

This is not the same failure as cross-vault selection or browser origin validation. Here the caller already has access to the vault but can request paths that the application should deny even if they are absent from the index. The July 3 version 1.3.1 correction applies the sensitive-directory deny rules to read, write and delete operations and repairs strictReadDefault on direct requests.

The same caller could see an innocent directory listing and still obtain a sensitive hidden path when requesting it exactly. The server used an enumeration filter without a corresponding decision at file-open time, while an unset allowlist permitted broad access. This makes a negative listing result unreliable evidence of protection. A verified correction needs direct positive and negative path tests for .obsidian, .git and .trash, not only a check that those names disappear from listing output.