[Security] Path validation bypass on Windows via NTFS Alternate Data Streams (ADS) in secure-filesystem-server

[andreiminca]

A path validation bypass vulnerability has been identified on Windows environments within the secure-filesystem-server. The isPathWithinAllowedDirectories function fails to restrict NTFS Alternate Data Streams (ADS). As a result, an attacker can supply paths containing a colon separator (e.g., file.txt:payload.exe), which bypasses directory boundary checks and allows reading or writing hidden data directly to NTFS alternate streams within allowed folders

Description

This change introduces validation to reject paths containing NTFS Alternate Data Streams (ADS) on Windows platforms. It inspects the normalized path in isPathWithinAllowedDirectories and blocks paths that contain unexpected colons (:) beyond the standard Windows drive letter prefix (e.g., C:).

Publishing Your Server

Note: We are no longer accepting PRs to add servers to the README. Instead, please publish your server to the MCP Server Registry to make it discoverable to the MCP ecosystem.

To publish your server, follow the quickstart guide. You can browse published servers at https://registry.modelcontextprotocol.io/.

Server Details

• Server: filesystem
• Changes to: path-validation.ts (internally used by all filesystem tools)

Motivation and Context

On Windows machines using NTFS, files can have alternate data streams using the filename:streamname syntax. The existing validation normalized the path and verified the directory prefix (e.g., normalizedPath.startsWith(normalizedDir + path.sep)).

However, since path.resolve and path.normalize on Windows preserve the : separator, a path like C:\allowed\dir\safe.txt:payload.exe would start with the allowed directory prefix and bypass validation. When used in file reads or writes, Node.js and Windows would access the alternate stream instead of a regular file. This fix solves this bypass by validating and rejecting any unexpected colons on Windows, while preserving full compatibility with Linux/Unix platforms where colons are valid characters in filenames.

How Has This Been Tested?

Tested the function isPathWithinAllowedDirectories with the following test cases:

• Windows absolute paths (e.g., C:\allowed\dir\file.txt) -> Allowed
• Windows paths with Alternate Data Streams (e.g., C:\allowed\dir\file.txt:payload.exe) -> Rejected
• Windows paths with multiple colons (e.g., C:\allowed\dir\file.txt:stream1:stream2) -> Rejected
• Standard Linux paths with colons (e.g., /allowed/dir/file.txt:with:colons) -> Allowed (retaining compatibility)

Breaking Changes

None. This is a non-breaking security fix.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

The fix specifically isolates Windows platforms (process.platform === 'win32' || path.sep === '\\') to prevent breaking compatibility on POSIX systems where colons are valid file system characters.