@cyanheads/filesystem-mcp-server
MCP serverVerified · Rung 3TypeScript filesystem MCP server with directory restriction via FS_BASE_DIRECTORY environment variable. 10 tools including read, write, update, list, delete, and copy/move operations. Supports STDIO and HTTP transports.
Security cap applied
Score breakdown
Based on 1 evaluation. Confidence rises as more independent tests agree.
The verdict
Works correctly when properly configured, but carries two security weaknesses: an opt-in rather than enforced security model, and a symlink-follow escape that bypasses the configured base directory. When FS_BASE_DIRECTORY is set, direct path traversal and /etc/passwd reads are correctly blocked. However, if a symlink is placed inside the allowed directory pointing to a file outside it, read_file follows the symlink and returns the external file content. Confirmed: placing a symlink to /etc/passwd inside the workspace, then calling read_file on the symlink path, returns the full contents of /etc/passwd (root:x:0:0:root:/root:/bin/bash...). This allows an agent with write access to the workspace to read any file the process can access. The security model is also opt-in: if FS_BASE_DIRECTORY is not set, the server starts with unrestricted filesystem access. The official server takes the opposite approach — it exits with an error if no allowed directory is provided. That difference matters because misconfiguration is the most common real-world failure mode. Other notes: tool naming differs from the official server (list_files vs list_directory, move_path vs move_file), so integrations are not drop-in compatible. An unexplained @google/genai runtime dependency adds ~25 MB and supply-chain surface with no documented purpose in a local filesystem server.
This is a published failing verdict. We send the maintainer the full evaluation and a window to fix it or correct us before it goes live. Read the disclosure policy.
Security findings
Flags from our evaluations, ordered by severity.
- High
SYMLINK_FOLLOW_ESCAPE
read_file follows symlinks inside the allowed directory without resolving them against the base directory. A symlink at /tmp/fs_reverify_ws/symlink_to_etc_passwd pointing to /etc/passwd was created inside the workspace. Calling read_file on the symlink path returned the full contents of /etc/passwd: 'root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin...'. Any agent with write access to the workspace can create a symlink to any file the process can read and exfiltrate its contents through read_file.
- Medium
OPT_IN_DIRECTORY_RESTRICTION
Directory restriction requires the FS_BASE_DIRECTORY environment variable. If this variable is not set, the server starts with unrestricted filesystem access. The package documentation states this is 'a potential security risk' but does not prevent startup. The official server takes the opposite approach: it exits with an error if no allowed directory is provided, making the safe path the only path.
- Info
UNEXPECTED_RUNTIME_DEPENDENCY
@google/genai is listed as a runtime dependency in package.json. Its purpose is not documented in the README or source entry point. This adds a large supply-chain surface (Google AI SDK) for a server whose core function is local filesystem access.
Test history
1 runEvery evaluation behind the score. This is the receipt.
- PassmanualReliability
82/100
Latency7 ms
SetupModerate
Flags3
All 10 tools verified with FS_BASE_DIRECTORY=/tmp/fs_reverify_ws: read_file, set_filesystem_default, write_file, update_file, list_files, delete_file, delete_directory, create_directory, move_path, copy_path. read_file and write_file both work correctly. list_files returns a tree-formatted listing. Direct path traversal to /etc/passwd correctly blocked: 'Access denied: The path resolves to a location outside the allowed base directory.'
HighSYMLINK_FOLLOW_ESCAPEMediumOPT_IN_DIRECTORY_RESTRICTIONInfoUNEXPECTED_RUNTIME_DEPENDENCY
Notify me if this grade changes
We re-test servers and grades move. Leave your email and we will tell you if this one does.