Filesystem MCP Path Prefix Boundaries: Reject Similar Sibling Directories
A text-prefix check can mistake a similarly named sibling for a child of an allowed directory. The official advisory and patch show why containment requires path-component boundaries and deployed-artifact verification.
Read in JapaneseThe official Model Context Protocol servers project published an advisory for a Filesystem MCP vulnerability in which a separate directory with a colliding prefix could be mistaken for part of an allowed directory. The defect did not arise from file access itself. It broke the endpoint of the granted scope: a plain string comparison could not distinguish a true child from a sibling whose name began with the same characters.
String prefixes are not directory ancestry
Assume /srv/team is allowed. /srv/team/report.csv is below the team directory, while /srv/team-archive/report.csv and /srv/team2/report.csv are siblings. All three strings begin with /srv/team, so a simple startsWith decision cannot enforce the intended boundary.
| Requested path | Text prefix | Component boundary | Adoption decision |
|---|---|---|---|
/srv/team | Match | Allowed directory itself | Candidate for access |
/srv/team/reports/q3.csv | Match | Child after a path separator | Candidate for access |
/srv/team-archive/q3.csv | Match | No separator after team | Reject |
/srv/team2/q3.csv | Match | Different directory name | Reject |
The official patch changes containment so that a normalized requested path must either equal an allowed directory or begin with that directory followed by the operating system's path separator. Its tests explicitly reject sibling names such as project2, project_backup, and project-old. Normalization handles representational differences such as . segments, .. segments, repeated separators, and trailing separators; the component-boundary check then answers the separate question of directory ancestry.
Checks for an adoption record
Create a harmless sibling directory that shares the allowed prefix. Using the actual package artifact and launch configuration, confirm that normal files inside the allowed directory support the operations the workflow needs, while the sibling is rejected for reads, writes, and listings. With multiple allowed directories, retain results for an exact match, a legitimate child, and a colliding sibling for each root. This provides evidence about the deployed path rather than only the source repository.
Version evidence needs separate attention. For the 0.x release line, the publisher advisory's patched-versions table lists 0.6.3, while its prose recommends upgrading to 0.6.4. Do not turn that inconsistency into an unsupported fixed-version claim. Reconcile the publisher's current recommendation with the exact deployed artifact and confirm that the official patch or its equivalent is present. A lockfile alone does not establish what a container image or package cache is running.
Add an enforcement layer outside the server. Expose only task-specific working directories through container mounts or OS permissions and use a dedicated account without access to unrelated host data. If path validation regresses, these controls reduce what the process can reach. This follows the MCP security policy's trust model: a local server receives the resources available in its execution context, and operators remain responsible for appropriate permissions.
Scope and limitations
This analysis uses the official advisory, patch commit, and MCP security policy reviewed on September 22, 2026. It is not an MCP Guard discovery, a fresh inspection of a deployment, or evidence that every current Filesystem MCP package remains affected. Component-aware comparison closes the colliding-prefix error; it does not by itself settle symlink destinations, filesystem case rules, network filesystem behavior, or replacement races between validation and access.