CVE-2026-57441 in MCPVault
Summary
by MITRE • 09/15/2026
MCPVault is a lightweight Model Context Protocol server for safe access to files in an Obsidian vault. Prior to 0.11.4, PathFilter in src/pathfilter.ts compiles restricted-directory patterns case-sensitively and compares paths without canonicalizing filesystem-equivalent segment names. On case-insensitive macOS and Windows filesystems, case variants of .git, .obsidian, or node_modules pass both isAllowed() and isAllowedForListing() even though the operating system opens the restricted directory, and Windows trailing dots or spaces provide the same bypass. An attacker who influences a path selected by an AI agent can use the bypass in read, write, move, search, or listing operations to expose or modify sensitive repository and Obsidian metadata. Vault-root .. containment is not affected. This issue is fixed in version 0.11.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in MCPVault prior to version 0.11.4 represents a critical path traversal and access control bypass rooted in improper handling of filesystem semantics across different operating systems. As a lightweight Model Context Protocol server designed to provide safe access to files within an Obsidian vault, the application relies on strict filtering mechanisms to prevent unauthorized exposure or modification of sensitive data. The core flaw resides in the PathFilter component located in src/pathfilter.ts, which fails to account for case-insensitivity and filesystem normalization quirks inherent to macOS and Windows environments. This oversight allows attackers to circumvent security restrictions by exploiting discrepancies between how the application validates paths and how the underlying operating system resolves them.
The technical mechanism of this vulnerability involves two primary failure modes: case-sensitivity mismatches and trailing character anomalies. The PathFilter compiles restricted-directory patterns, such as .git, .obsidian, or node_modules, using case-sensitive comparisons. On case-insensitive filesystems like those found in macOS (HFS+ or APFS) and Windows (NTFS), the operating system treats file paths with different letter casing as identical. Consequently, an attacker can construct a path that uses mixed-case variations of restricted directory names to bypass the isAllowed() and isAllowedForListing() checks. For instance, while the filter might block .git, it would permit access via .Git or .GIT because the regex pattern matching does not normalize case before evaluation. Furthermore, on Windows systems, trailing dots and spaces in file paths are often stripped by the operating system during resolution but may be preserved in string comparisons performed by the application logic. This discrepancy allows an attacker to append these characters to a restricted path name to evade detection while still accessing the target directory through the OS interface.
The operational impact of this vulnerability is significant, particularly given the context of AI-driven file operations. An adversary who can influence or manipulate the paths selected by an integrated AI agent can exploit this bypass to perform unauthorized read, write, move, search, and listing operations within restricted directories. This capability enables the exposure of sensitive repository metadata stored in .git folders, such as commit history, configuration files, or potentially hardcoded credentials if present. Similarly, access to the .obsidian directory could reveal user preferences, plugin configurations, and private note contents that were intended to be isolated from general AI processing. The ability to modify these directories further risks corrupting vault integrity or injecting malicious content into the knowledge base processed by the AI agent. Although the vulnerability does not affect containment of the vault root via relative path traversal using double dots (..), it effectively neutralizes directory-level isolation controls, allowing lateral movement within the file system structure beyond intended boundaries.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-73 External Control of File Name or Path. The failure to canonicalize filesystem-equivalent segment names constitutes an input validation error where the application does not normalize user-supplied data before security checks. Additionally, because the vulnerability allows unauthorized access to restricted directories through manipulation of path strings, it maps directly to ATT&CK technique T1083 File and Directory Discovery. This technique is frequently used by adversaries to map out a target environment for subsequent exploitation or exfiltration activities. The specific bypass mechanisms involving case sensitivity and trailing characters are well-documented evasion techniques that security controls must explicitly address through robust normalization strategies rather than relying on simple string matching.
Mitigation of this vulnerability requires immediate updates to the PathFilter logic in src/pathfilter.ts. Developers should implement path canonicalization before performing any access control checks, ensuring that all paths are resolved to their absolute, normalized forms regardless of case or trailing whitespace anomalies. Utilizing standard library functions provided by Node.js for resolving and normalizing paths is essential to ensure consistency across different operating systems. Additionally, implementing case-insensitive pattern matching when running on platforms known to be case-insensitive will prevent the bypass described above. Organizations relying on MCPVault should upgrade to version 0.11.4 or later immediately, as this release contains the necessary fixes for these path handling deficiencies. Until an update is applied, administrators should restrict AI agent permissions and monitor file system access logs for unusual patterns involving restricted directories with anomalous casing or trailing characters.