CVE-2025-67366: filesystem-mcp Path Traversal Flaw

CVE-2025-67366 Overview

A critical path traversal vulnerability has been identified in @sylphxltd/filesystem-mcp version 0.5.8, an MCP (Model Context Protocol) server that provides file content reading functionality. This vulnerability exists in the read_content tool and stems from improper symlink handling in the path validation mechanism. The flaw allows attackers to bypass directory restrictions and access sensitive files outside the intended operational scope.

Critical Impact

Attackers can leverage symlinks within allowed directories to read arbitrary files on the system, potentially exposing sensitive configuration files, credentials, and other confidential data.

Affected Products

• @sylphxltd/filesystem-mcp v0.5.8
• MCP server implementations using the vulnerable read_content tool
• Applications relying on filesystem-mcp for sandboxed file access

Discovery Timeline

• 2026-01-07 - CVE-2025-67366 published to NVD
• 2026-01-08 - Last updated in NVD database

Technical Details for CVE-2025-67366

Vulnerability Analysis

This path traversal vulnerability (CWE-23: Relative Path Traversal) exploits a critical timing mismatch between path validation and file access operations. The resolvePath function performs its security checks on the path string before symlinks are resolved. However, when fs.readFile subsequently processes the validated path, it automatically resolves any symlinks encountered during file access.

This creates a time-of-check to time-of-use (TOCTOU) race condition where the validated path differs from the actual file being accessed. An attacker who can create or leverage existing symlinks within the allowed directory can effectively escape the sandboxed environment and read files anywhere on the filesystem.

The vulnerability is particularly dangerous in environments where the filesystem-mcp server is used to provide controlled file access to AI models or automated systems, as it undermines the entire security boundary.

Root Cause

The root cause lies in the order of operations within the path validation logic. The resolvePath function validates paths in their symbolic form rather than their canonical, fully-resolved form. When a user requests access to a path like /allowed/symlink, the validation passes because /allowed/ is within the permitted scope. However, if symlink points to /etc/passwd, the subsequent fs.readFile call will follow the symlink and return the contents of the external file.

The proper approach would be to resolve all symlinks first using fs.realpath() and then validate whether the canonical path falls within the allowed directories.

Attack Vector

The attack requires network access to the MCP server. An attacker can exploit this vulnerability by:

1. Identifying or creating a symlink within an allowed directory that points to a target file outside the sandbox
2. Requesting the symlinked path through the read_content tool
3. Receiving the contents of the external file, bypassing all directory restrictions

The vulnerability requires no authentication or user interaction to exploit, making it accessible to any network-connected attacker who can communicate with the MCP server.

For technical details on this vulnerability, refer to the GitHub Issue #134 Discussion which documents the symlink handling flaw. The attack leverages the discrepancy between validation-time path checking and access-time symlink resolution in the read_content tool implementation.

Detection Methods for CVE-2025-67366

Indicators of Compromise

• File access logs showing reads of sensitive system files (e.g., /etc/passwd, /etc/shadow, private keys) through the MCP server
• Unusual symlink creation events within directories accessible to the filesystem-mcp service
• Access patterns indicating systematic enumeration of symlinked paths
• Log entries showing successful file reads for paths that should be outside the allowed scope

Detection Strategies

• Monitor filesystem-mcp server logs for file access requests containing symlink references
• Implement file integrity monitoring on critical system files to detect unauthorized reads
• Deploy behavioral analysis to identify patterns consistent with directory traversal exploitation
• Configure audit logging to track symlink creation and resolution within allowed directories
• Use SentinelOne's Storyline technology to correlate file access events with network connections to the MCP server

Monitoring Recommendations

• Enable verbose logging on the filesystem-mcp server to capture all file access requests
• Set up alerts for access attempts to sensitive file paths commonly targeted in path traversal attacks
• Monitor for anomalous file read patterns that deviate from normal application behavior
• Implement real-time correlation of file access events with the process context to identify exploitation attempts

How to Mitigate CVE-2025-67366

Immediate Actions Required

• Restrict network access to the filesystem-mcp server to trusted clients only
• Audit all symlinks within directories accessible to the MCP server and remove any pointing outside the intended scope
• Implement network-level access controls to limit exposure of the vulnerable service
• Consider temporarily disabling the read_content tool until a patch is applied

Patch Information

Users should monitor the GitHub Repository for Filesystem MCP for security updates addressing this vulnerability. Review GitHub Issue #134 for the latest information on patches and fixes.

Until an official patch is released, organizations should implement the workarounds below to reduce exposure to this vulnerability.

Workarounds

• Remove or disable symlinks within directories accessible to the filesystem-mcp service
• Implement additional validation at the application layer to resolve and verify canonical paths before file access
• Deploy a reverse proxy or API gateway with path validation rules that reject requests containing symlinks
• Run the filesystem-mcp server in a containerized environment with restricted filesystem access
• Use filesystem mount options like nosymfollow where supported to prevent symlink traversal

# Configuration example
# Disable symlink following on the filesystem level (Linux)
# Mount the allowed directory with nosymfollow option
mount -o remount,nosymfollow /path/to/allowed/directory

# Alternatively, audit existing symlinks in the allowed directory
find /path/to/allowed/directory -type l -exec ls -la {} \;

# Remove symlinks pointing outside the allowed scope
find /path/to/allowed/directory -type l ! -exec test -e {} \; -delete