The Local REST API's /vault/{path} endpoints decode the URL-encoded path after Express routing, which normalizes and rejects literal ../ sequences but does not treat %2F as a separator. This allows encoded traversal sequences (e.g., ..%2F..%2F) to bypass routing checks and be decoded into ../ sequences inside the handler, escaping the vault root. The decoded path is passed directly to the vault adapter without confinement checks, enabling arbitrary file read, write, and delete operations on the host filesystem with the Obsidian process's privileges. The MOVE operation has a confinement check using posix.resolve and prefix validation, but this is missing from other HTTP methods. The recommended fix is to apply the same confinement check to all vault handlers to reject traversal outside the vault root.

An authenticated attacker can perform arbitrary file read, write, and delete operations on the host filesystem outside the Obsidian vault directory. This can lead to exposure or modification of sensitive user files such as SSH keys, browser profiles, dotfiles, and credentials. The impact is elevated by the fact that the Obsidian process typically runs with the user's privileges. In deployments where the API is used as a server for multi-client processing or LLM agents, this vulnerability can be exploited to escalate from note editing to full filesystem access without explicit user intent.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability can be mitigated by applying a confinement check similar to the one used in the MOVE operation: use posix.resolve to resolve the decoded path against a synthetic root (/vault) and reject any path that escapes this root. Reject any path segments that decode to '..' or result in traversal outside the vault directory. Until an official fix is released, users should restrict access to the Local REST API to trusted clients only and consider disabling it if not needed.