[Security] Directory Traversal via Symbolic Link Bypass Leading to Arbitrary Read/Write

[ItsCrem]

Outline

The isPathAllowed function for validating file operations is vulnerable to a security bypass using symbolic links (symlinks). The function does a good job of validating traditional directory traversal attacks (e.g., ../../../) by normalising the path. It validates that a path string starts with an allowed directory, but it does not resolve symlinks. An attacker can create a symlink inside an allowed directory that points to a restricted location. The check will pass, but the subsequent file operation will follow the symlink, leading to an arbitrary file read/write.

Proof of Concept

In this example, the following directory structure is used:

• /tmp/base/safe/ (This will be the allowed directory)
• /tmp/base/secret/secrets_file (This is a sensitive file in a restricted directory)

The following image illustrates the directory structure:

1. Set up DesktopCommanderMCP with an MCP Client (this example uses Cline).
2. As no allowedDirectory is set by default, ask your MCP client to use set_config to set /tmp/base/safe as an allowedDirectory.
3. Send a request to read the file /tmp/base/secret/secrets_file. It should correctly respond that access is not allowed.

4. Run the following command in your terminal to create a symlink inside the safe folder that points to the secret file:

ln -s /tmp/base/secret/secrets_file /tmp/base/safe/diego

After the symlink is established, the directory structure now looks like this:

5. Finally, send a request to read the file /tmp/base/safe/diego. It will successfully print the contents of the secrets_file.

Note: the same thing can be done with any of the File System operations such as write_file.

---

This works because the function only checks whether the path string begins with an allowed directory and does not resolve the symlink to its true destination.

Impact

This vulnerability completely bypasses the directory restrictions, allowing an attacker to read or write arbitrary files on the system with the permissions of the running process. This can lead to sensitive data exposure (e.g., SSH keys, configuration files) or code execution if an attacker can write to executable files. The severity would vary depending on the privileges of the user running the server.

Recommended Fix

Before performing the security check, the isPathAllowed function must resolve the true, canonical path of the user-provided input, including all symbolic links. In Node.js, this should be done using fs.realpathSync().

Note: I reached out to the maintainer to responsibly disclose this vulnerability and was asked to post the details in the GitHub issues.

[wonderwhy-er]

Thank you for your detailed research and responsible disclosure, Max. This is a well-documented vulnerability report.

Our perspective: The key question we have is "who will be creating symlinks that bypass restrictions?" This highlights an important aspect of our threat model.

Current reality: We have multiple bypass vectors beyond symlinks - the biggest being code execution that can circumvent most blocks anyway. Our restriction features are designed as guardrails for LLMs to help them stay closer to what users want, rather than hardened security boundaries.

Our recommendation: For users where security is a top priority, we continue to recommend using Desktop Commander with Docker, which provides actual isolation. Here are installation instructions.

Future consideration: We could potentially add a setting to allow/disallow symlink following, but we'd like to see real workflow requests from users before prioritizing this work. We'll keep this issue open for future consideration if we receive more user demand for improved restrictions.

Thank you again for your research - it helps us understand the current limitations better.