Filesystem MCP Symlink Boundaries: Match Allowed Paths to Real Paths
A symlink that appears inside an allowed directory may resolve to a file outside it. The official advisory and patch turn real-path validation, deployed-package review, and OS isolation into concrete adoption conditions.
Read in JapaneseThe official Model Context Protocol servers project published an advisory for a Filesystem MCP vulnerability in which a symlink inside an allowed directory could reach an unintended file. The broken boundary was the agreement between where a path string appeared to be and what object the operating system would ultimately open. File access is an intended Filesystem MCP capability; reaching beyond the configured scope is a separate security defect.
Lexical paths and physical destinations
Suppose /work/approved is allowed, but latest inside it is a symlink to /private/archive. The string /work/approved/latest/report.pdf appears to be in scope, yet its physical destination is not. A safe containment decision therefore has to consider the path after symlink resolution. The destination must be the allowed directory itself or a true descendant of it.
| Review point | Insufficient evidence | Acceptance evidence |
|---|---|---|
| Allowed directory | Saved configuration string | Resolved startup path matches the intended directory |
| Existing file | Requested-path prefix | Real path after symlink resolution remains in scope |
| New file | Automatic approval because it does not exist | Existing parent resolves in scope before creation |
| Execution environment | Server-side check alone | Mounts or OS permissions also hide unnecessary host paths |
The official patch resolves allowed directories at startup, rechecks the real path of an existing target, and adds tests for links that point outside the allowlist. For a target that does not yet exist, it validates the resolved parent. These changes shift the decision from the visible name to the destination that a file operation can reach.
Evidence to retain before adoption
Record the source and exact deployed artifact of @modelcontextprotocol/server-filesystem, rather than relying only on a dependency declaration. The publisher advisory has a material inconsistency for the 0.x release line: its patched-versions table lists 0.6.3, while the prose recommends upgrading to 0.6.4. Do not settle that discrepancy by selecting the lower number. Check the publisher's current recommendation, the artifact actually installed, and whether it contains the relevant patch.
In a non-sensitive test area, verify both sides of the boundary. A symlink whose destination remains inside the allowed directory should support the operations your workflow needs. A symlink pointing outside it should be rejected for both reads and writes. If the workflow creates files, include a case where an existing parent directory is itself a symlink. Keep the test tied to the same package artifact and launch configuration used in production.
Apply a second boundary at the operating system or container layer. Mount only the working directories needed for the task and run the server with an account that cannot read unrelated material. A process cannot expose a host path it cannot see, even if application-level validation later regresses. The MCP security policy makes this deployment responsibility explicit: local servers receive the resources available in their execution context, and the stdio transport is not a sandbox.
Scope and limitations
This analysis is based on the official advisory, patch commit, and MCP security policy reviewed on September 22, 2026. It does not claim that MCP Guard discovered the issue, report a fresh inspection of any deployment, or estimate prevalence. Reading the public patch does not prove that a lockfile, container image, or cached package contains it. Real-path validation is necessary for this boundary, but it is not by itself proof against every file-replacement race or operating-system-specific behavior.