Back to Blog 

TL;DR
- CVE-2025-53109 and CVE-2025-53110 ("EscapeRoute") are CVSS 7.3 High vulnerabilities (NVD; Cymulate, the discoverer, scored CVE-2025-53109 at 8.4) in Anthropic's official Filesystem MCP server, disclosed by Cymulate in July 2025.
- CVE-2025-53109 is a symlink-following attack: the server resolved symlinks pointing outside its configured root, allowing arbitrary read/write outside the sandbox.
- CVE-2025-53110 is a path-prefix bypass: the server used string-prefix comparison to enforce its directory boundary, which could be bypassed by paths whose prefix matched but whose actual filesystem location did not.
- The CVSS 7.3 "High" rating understates real-world severity. Both CVEs produce arbitrary file read and code execution outside the configured root, on developer workstations that typically hold credentials, source code, and active session tokens.
- The structural lesson: application-layer sandboxes are not sandboxes. Path-string comparison and symlink-resolution checks live in user-space code that is exactly what attackers target. Effective filesystem isolation requires kernel-enforced boundaries —
chroot, mount namespaces,openat2withRESOLVE_BENEATH, or container-level path constraints.
What the Filesystem MCP server does
Anthropic's Filesystem MCP server is one of the most widely-used MCP servers in production. It provides AI agents with a controlled interface for reading and writing files — the agent can list directories, read file contents, write files, and create directories within a configured root path. The server is shipped with Anthropic's reference implementation and adopted broadly across the MCP ecosystem.
The configured root is the security boundary. The operator specifies "the agent can access this directory and nothing else." Every tool invocation is supposed to be checked against the boundary before any filesystem operation occurs. The check failed in two distinct ways, producing the EscapeRoute pair.
CVE-2025-53109 — Symlink Following
What it does
The Filesystem MCP server resolved file paths through Node.js filesystem operations that follow symbolic links by default. An attacker who could place a symlink inside the configured root pointing to a target outside the root could use the symlink as a portal — agent operations against the symlink's path would actually operate on the link target, bypassing the boundary check that only inspected the source path.
Why it works
The validation code checked whether the requested path's string was inside the configured root. It did not verify that the resolved path (after symlink traversal) was inside the root. The two diverge whenever a symlink crosses the boundary. Once the agent operated on the symlink, the OS filesystem layer transparently resolved the link to its target — and the target was wherever the attacker pointed it.
Severity (CVSS 7.3 High)
The exploit prerequisites are modest: an attacker needs to be able to place a symlink inside the configured root, which any agent action that accepts user-controlled paths will support. Once the symlink is in place, every subsequent read or write through the MCP server can be redirected outside the sandbox. The "High" rating reflects the prerequisite; in deployments where agents accept any external file content, the prerequisite is trivially satisfied.
CVE-2025-53110 — Path-Prefix Bypass
What it does
The Filesystem MCP server enforced its directory boundary using string-prefix comparison: a requested path was allowed if and only if it started with the configured root's path string. This breaks for paths whose string starts with the root but whose actual filesystem location does not — the most common case being symlinks whose names begin with the root path string but resolve elsewhere, or paths that exploit OS-specific path normalisation behaviours where the string-prefix-match accepts a path the kernel later resolves to an unintended target.
Why it works
Path-prefix comparison is a classical sandbox-escape primitive. It conflates "the path string starts with X" with "the path resolves inside X." The two are not the same. Any path string
${ROOT}/../../etc/passwd will pass a naive prefix check (it starts with ${ROOT}/) while the kernel resolves it to a target outside the root. Variants with double slashes, encoded path separators, or trailing whitespace add further bypass primitives that vary by OS.Severity (CVSS 7.3 High)
The prerequisite is even more modest than CVE-2025-53109: the attacker needs only to influence the path argument in a single tool call. Many agent integrations accept paths from documents, tool outputs, or other indirect sources, making this a low-cost exploit primitive.
Why CVSS understates the impact
The CVSS 7.3 "High" rating reflects the standard scoring formula, which considers attack-complexity and authentication-required as the primary modulators. But the actual impact of either CVE on a developer workstation is substantially worse than the rating suggests:
- The Filesystem MCP server typically runs in the developer's process space, with the developer's UID and environment.
- The configured root is typically a project directory inside the user's home directory.
- Bypassing the root means the agent can read or write anywhere the developer can — including
~/.aws/credentials,~/.ssh/, browser cookie stores, password manager files, hardware-wallet bridge state.
In practical terms, EscapeRoute is a credential-exfiltration primitive plus a code-execution primitive (any path the developer can write to is reachable, including those that auto-execute on next shell launch). Calling it CVSS 7.3 High is technically correct and operationally misleading.
The structural lesson: application-layer sandboxes are not sandboxes
Both EscapeRoute CVEs share a single structural failure: the sandbox boundary lived in application-layer code. The Filesystem MCP server's path-validation logic was a check inside user-space JavaScript. The attacker's job was to find a path string that the check approved but the kernel's filesystem layer resolved differently. There were always going to be such paths — the variety of OS-specific path normalisation behaviours, symlink-following semantics, and filesystem race conditions ensures that user-space path validation cannot be exhaustive.
This is a generalised lesson, not specific to the Filesystem MCP server:
Path validation in application code is bypassable. Decades of CVE history demonstrate this. Every project that has tried to enforce a "the agent can only access this directory" rule via path-string comparison has eventually shipped a CVE for the same reason.
Symlink semantics are OS-defined, not application-defined. When the application calls
fs.readFile, the kernel resolves the path. The application does not get to override the kernel's resolution rules.Race conditions add a third bypass class. Even with perfect path validation, TOCTOU (time-of-check / time-of-use) races allow attackers to swap the resolution target between the validation step and the operation step.
Effective filesystem isolation requires kernel-enforced boundaries:
chrootjails restrict the filesystem view such that the kernel itself cannot reach paths outside the jail.- Mount namespaces (Linux) and equivalent OS primitives restrict which filesystems are visible to the process.
openat2withRESOLVE_BENEATH/RESOLVE_NO_SYMLINKS(Linux 5.6+) enforces that the kernel rejects path resolutions that escape the configured root.- Container-level path constraints (Docker, containerd, OCI) use mount points to isolate the filesystem.
The fix in subsequent Filesystem MCP server versions used
realpath resolution plus explicit symlink-target validation against the configured root. This is better than the original prefix check, but it still operates in application-layer code; the underlying lesson is that any operator running an MCP server with filesystem access should run it inside a kernel-enforced boundary regardless of what application-layer checks the server itself implements.Where this fits in the OWASP standard
EscapeRoute maps cleanly to several items in the OWASP Top 10 for Agentic Applications:
- ASI05 (Unexpected Code Execution) by impact: arbitrary file read and write on a developer workstation produces credential theft and lateral execution paths.
- ASI04 (Agentic Supply Chain) by transitive risk: the vulnerable server ships as part of the official MCP toolchain, so any operator who installed it inherited the exposure.
- ASI02 (Tool Misuse) by mechanism: the tool's authority was supposed to be scoped to a directory; the scope did not hold.
A complete audit report typically maps the finding to all three.
Detection and mitigation
For any MCP server that accepts paths or operates on the filesystem:
1. Run inside a kernel-enforced boundary. Container, mount namespace,
chroot, or platform equivalent. The application's own boundary checks are belt-and-braces; the actual security comes from the kernel-level layer.2. Use
realpath resolution before any check. The validation must run against the resolved path, not the requested path. The Filesystem MCP server's post-EscapeRoute fix does this.Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.
3. Reject all symlinks crossing the boundary. Even resolved-path validation can be bypassed by TOCTOU if the symlink is created after validation but before use. Refuse paths whose resolution traverses any symlink whose target is outside the boundary.
4. Use
openat2 with RESOLVE_BENEATH on Linux. This is the kernel-level guarantee that the resolution does not escape. Application code can still be wrong; the kernel will reject the operation regardless.5. Run the server with constrained credentials. The MCP server process should not inherit the developer's full environment. Run it with a dedicated UID, restricted environment variables, and no access to credential stores or session tokens outside the configured root.
For Web3 deployments specifically, the rule is unconditional: any MCP server with filesystem access must run in a process boundary that cannot reach wallet keystores, hardware-wallet bridge state, or signing-related session tokens regardless of what paths the configured root permits.
How Zealynx audits filesystem-touching MCP servers
A Zealynx MCP Security Audit treats EscapeRoute-class findings as a standard category. The five focused tests:
- Boundary-enforcement layer audit. Identify whether the server's filesystem boundary lives in application code, kernel code, or both.
- Symlink test battery. Submit symlinks crossing the boundary in every supported direction; verify the server rejects each.
- Path-normalisation test battery. Submit paths exploiting OS-specific normalisation quirks (encoded separators, trailing whitespace, double slashes, dot-segments); verify the server rejects each.
- TOCTOU race test. Verify whether the server's check-then-use pattern is atomic; flag any time gap an attacker can exploit.
- Privilege-envelope check. Verify the server runs with constrained credentials and cannot reach the developer's broader environment.
Findings map to the relevant OWASP items and prioritised by exploit difficulty plus blast radius.
FAQ
1. What is EscapeRoute?
EscapeRoute is the researcher name for CVE-2025-53109 and CVE-2025-53110, a pair of CVSS 7.3 High vulnerabilities in Anthropic's official Filesystem MCP server disclosed by Cymulate in July 2025. CVE-2025-53109 is a symlink-following attack where the server resolved symlinks pointing outside its configured root. CVE-2025-53110 is a path-prefix bypass where the server used string-prefix comparison to enforce its directory boundary. Both produce arbitrary file read and write outside the sandbox.
2. Why is the CVSS 7.3 High rating misleading?
The CVSS 7.3 rating reflects the standard scoring formula's treatment of attack complexity and required authentication. It understates real-world impact because the Filesystem MCP server typically runs in the developer's process space with the developer's UID and environment, and the configured root is typically a project directory inside the user's home. Bypassing the boundary means the agent can read or write anywhere the developer can — including
~/.aws/credentials, ~/.ssh/, browser cookie stores, password managers, hardware-wallet bridge state. The practical impact is credential exfiltration plus code execution.3. How does CVE-2025-53109 differ from CVE-2025-53110?
CVE-2025-53109 is a symlink-following attack: the server resolved symlinks pointing outside the configured root, so an attacker who could place a symlink inside the root could use it as a portal to anywhere the developer could access. CVE-2025-53110 is a path-prefix bypass: the server checked whether the requested path string started with the root's path string, which can be bypassed by paths that pass the string check but resolve elsewhere. They share a root cause (application-layer path validation that diverges from kernel-level path resolution) but exploit it through different primitives.
4. What is the structural lesson from EscapeRoute?
The structural lesson is that application-layer sandboxes are not sandboxes. Path validation in application code can be bypassed by symlinks, by OS-specific path normalisation behaviours, and by TOCTOU races between check and use. Effective filesystem isolation requires kernel-enforced boundaries —
chroot, mount namespaces, openat2 with RESOLVE_BENEATH, or container-level path constraints. Any MCP server with filesystem access should run inside such a boundary regardless of what application-layer checks the server itself implements.5. How do I prevent EscapeRoute-class vulnerabilities?
To prevent EscapeRoute-class vulnerabilities, run filesystem-touching MCP servers inside a kernel-enforced boundary (container, mount namespace, chroot, or platform equivalent), use
realpath resolution before any boundary check, reject all symlinks crossing the boundary, use openat2 with RESOLVE_BENEATH on Linux for kernel-level guarantee, and run the server with constrained credentials so it cannot reach the developer's broader environment regardless of what paths the configured root permits.6. Are EscapeRoute CVEs still exploitable?
Both CVEs are patched in current Anthropic Filesystem MCP server releases. Operators on older versions remain vulnerable. The structural pattern — application-layer path validation diverging from kernel-level path resolution — is generic and applies to every MCP server that operates on filesystems with application-layer boundary enforcement, so equivalent vulnerabilities can re-emerge in other servers that have not implemented kernel-enforced boundaries.
7. What is "TOCTOU" and how does it apply to filesystem MCP servers?
TOCTOU (time-of-check / time-of-use) is a race-condition class where a security check and the subsequent operation are not atomic, allowing an attacker to swap the resolution target between the two steps. For filesystem MCP servers: the server validates that a path is inside the configured root, then opens the file. Between the validation and the open, an attacker can replace the path with a symlink pointing outside the root, and the open operates on the new target. Even perfect path validation cannot defend against TOCTOU; the only structural fix is atomic check-and-operate primitives like
openat2 with RESOLVE_BENEATH.8. How does Zealynx audit for these patterns?
Zealynx's MCP Security Audit tests filesystem-touching MCP servers across five dimensions: boundary-enforcement layer audit (application-layer vs kernel-layer), symlink test battery (every direction of symlink-crossing), path-normalisation test battery (OS-specific quirks), TOCTOU race tests (verifying atomic check-and-use), and privilege-envelope check (constrained credentials, no developer-environment inheritance). Findings map to the relevant OWASP items with prioritised remediation guidance.
Glossary
| Term | Definition |
|---|---|
| Symlink-Following Attack | A sandbox-escape pattern where an attacker places a symbolic link inside a sandboxed directory, pointing to a target outside the directory; subsequent operations through the link transparently resolve to the target, bypassing application-layer boundary checks that inspected only the source path. |
| Path-Prefix Bypass | A sandbox-escape pattern where a sandbox boundary check uses string-prefix comparison to enforce a directory boundary, allowing paths whose strings start with the root path but whose actual filesystem location does not. The CVE-2025-53110 mechanism. |
| TOCTOU (Filesystem) | Time-of-check / time-of-use race condition class where a security check and the subsequent filesystem operation are not atomic, allowing an attacker to swap the resolution target between the two steps and bypass the check. |
Get funded for your audit
Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.
No spam. Unsubscribe anytime.
