Security Advisory

CVE-2026-79534 : Symlink allow-list bypass in mark3labs/mcp-filesystem-server

Severity

Medium

CVSS 3.1

5.9

Published

September 22, 2026

Back to advisories

Table of Contents

Advisory details

Product:

mcp-filesystem-server (github.com/mark3labs/mcp-filesystem-server)

Affected versions:

v0.11.1 and main commit ba3f07f

Patched version:

CVSS 3.1 vector:

AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

CWE:

CWE-59 Improper Link Resolution Before File Access; CWE-22 Path Traversal

Publication status:

Pending publication on CVE.org

Summary

validatePath returns an unresolved path for a dangling symlink, so the write tools follow a planted link and create files outside the allowed directories.

Where the bug is

Confinement helper: validatePath in helper.go, the parent-directory fallback at line 75
Write tools that go through it: write_file, modify_file, copy_file, move_file, create_directory

How it works

validatePath uses filepath.EvalSymlinks to resolve the requested path and confirm it is inside an allowed directory. When EvalSymlinks reports that the target does not exist (os.IsNotExist, which is what a dangling symlink produces), the helper checks only the parent directory and returns the unresolved path instead of the resolved one.

So if someone has placed a dangling symlink inside an allowed directory that points outside it, a later write through any of the tools above follows that symlink and creates the target file outside the confined area. This only creates files. Existing files outside the allow-list are still rejected (line 79), and the attacker has to plant the symlink first. That is why it is rated Medium rather than High.

This is a different bug from the time-of-check to time-of-use race reported earlier as issue #63. In Traceforce's testing, the EvalSymlinks change proposed there does not address this separate dangling-symlink code path. It was reproduced end to end against the real server binary over its live MCP stdio transport. As a control, a symlink to an existing out-of-bounds file was still blocked while the dangling case got through. The build tested was the current main branch at commit ba3f07f, ahead of the v0.11.1 release tag. A fixed release is not yet available.

Impact

Successful exploitation allows creation of files outside the configured allowed directories, subject to the filesystem permissions of the account running the server.

How to fix it

Maintainers: in the dangling-symlink branch, fully resolve the intended final path and re-check the resolved location against the allow-list before returning it. Reject writes whose final path component is a symlink that resolves, or would resolve, outside an allowed directory.
Operators: keep the allowed directories to trusted locations, and do not grant the write tools over directories that untrusted parties can seed with symlinks.