Path-Prefix Bypass

Path-Prefix Bypass is a sandbox-escape pattern where the boundary check uses string-prefix comparison to enforce a directory boundary, allowing paths whose strings begin with the configured root's path string but whose actual filesystem location does not. The pattern is the mechanism behind CVE-2025-53110 in Anthropic's official Filesystem MCP server, analysed in detail in the EscapeRoute writeup. It exists wherever an application conflates "this path string starts with X" with "this path resolves inside X."

The two are not the same. A path string /sandbox/../etc/passwd starts with /sandbox/ and passes a naive prefix check, but the kernel resolves it to /etc/passwd — entirely outside the sandbox. Variants include double-slash paths (/sandbox//../etc/passwd), encoded path separators (/sandbox/%2e%2e/etc/passwd), trailing whitespace (/sandbox/ /../etc/passwd), and OS-specific normalisation quirks where the same string resolves differently across platforms. Each variant adds another bypass primitive that the application's prefix-comparison code does not handle.

Why Path-Prefix Comparison Is Wrong

The prefix comparison treats the path as a string. The filesystem treats it as a sequence of resolution steps that can include parent-directory traversals, symbolic links, and OS-specific shortcuts. The two abstractions disagree, and the disagreement is exactly the attacker's tool. Decades of CVE history demonstrate this: any project that has tried to enforce a directory boundary via path-string comparison has eventually shipped a CVE for the same reason.

The structurally correct check operates on the resolved path. Call realpath (or platform equivalent) to resolve the requested path through all symlinks and parent traversals, then verify the resolved path is inside the configured root by walking the resolved path's segments rather than comparing strings. Even this is incomplete because of TOCTOU races between resolution and use, but it closes the most common exploit primitives.

Defensive Patterns

The kernel-enforced defence is to use openat2 with RESOLVE_BENEATH on Linux, mount namespaces, chroot, or container-level path constraints. These ensure the kernel itself rejects paths that escape the configured root, regardless of what the application's check did or did not implement.

For application-only environments, the conservative defence is: resolve the requested path with realpath; verify the resolved path is inside the root by component-wise walk (not string-prefix); refuse any path whose resolution traversed a symlink whose target is outside the root. The Filesystem MCP server's post-EscapeRoute fix uses this pattern. For deeper context, see the EscapeRoute case study and the MCP Security Checklist.