CVE-2026-79534 in Mcp-filesystem-server
Summary
by MITRE • 09/29/2026
mark3labs mcp-filesystem-server v0.11.1 is vulnerable to Directory Traversal due to an improper link resolution in validatePath (filesystemserver/handler/helper.go). When filepath.EvalSymlinks returns os.IsNotExist for a dangling symlink, the fallback validates only the parent directory and returns the unresolved path, so write_file (and modify_file, copy_file, move_file, create_directory) follows a pre-existing dangling symlink located inside an allowed directory and creates a file outside the configured allowed directories.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in mark3labs mcp-filesystem-server version 0.11.1 represents a critical security flaw rooted in improper link resolution logic within the validatePath function, specifically located in the filesystemserver/handler/helper.go module. This issue manifests as a directory traversal attack vector that allows an attacker to bypass intended access controls and write files outside of configured allowed directories. The core technical failure occurs when the system attempts to resolve symbolic links using filepath.EvalSymlinks. Under normal circumstances, this function resolves symlinks to their final targets to ensure path integrity. However, if EvalSymlinks encounters a dangling symlink—a symbolic link pointing to a non-existent target—it returns an error indicating that the file does not exist, specifically triggering os.IsNotExist conditions in the application logic rather than treating it as a fatal security violation or resolving it safely.
The operational impact of this flaw is significant because the fallback mechanism implemented by the developers fails to adequately secure the path validation process. Instead of rejecting the request due to the ambiguous state of the dangling symlink, the code proceeds with a partial validation that checks only the parent directory against the list of allowed directories. If the immediate parent directory is within an approved scope, the system accepts the path but returns the unresolved original input string rather than the resolved physical path. Consequently, when file manipulation operations such as write_file, modify_file, copy_file, move_file, or create_directory are executed using this returned value, they operate on the literal symlink target location defined by the attacker. Since dangling symlinks can be manipulated to point anywhere in the filesystem where the user has permission to create new links, an attacker can craft a request that appears valid during parent directory validation but ultimately results in file creation at arbitrary locations outside the sandboxed or allowed directories.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it allows access to files and resources located outside the intended restricted directory. Furthermore, from an offensive security perspective, this behavior is consistent with ATT&CK technique T1083: File and Directory Discovery combined with lateral movement or persistence mechanisms if the written file contains malicious payloads that are subsequently executed by other system components. The lack of strict validation on symlink targets creates a classic path traversal scenario where relative paths can be manipulated to escape directory boundaries, potentially leading to unauthorized data modification, denial of service through disk space exhaustion in critical system directories, or further exploitation depending on what services have write access to the affected locations.
To mitigate this vulnerability, immediate remediation is required by updating the validatePath function logic to handle dangling symlinks more securely. The most effective approach involves ensuring that if EvalSymlinks fails due to a non-existent target, the system should either reject the operation entirely or require additional verification steps such as checking if the symlink itself resides within an allowed directory and verifying that any potential future resolution would not lead outside those bounds before allowing write operations. Alternatively, implementing strict allow-listing of resolved paths rather than relying on partial parent checks can prevent this bypass. Developers must also consider using operating system-level restrictions or chroot environments to limit the impact even if such logic flaws occur in the application layer. Regular security audits focusing on file I/O handling and symbolic link resolution are recommended to identify similar patterns across other modules within the codebase, ensuring that all path validation mechanisms adhere to strict least-privilege principles and robust input sanitization standards.