Symlink-Following Attack

A Symlink-Following Attack is a sandbox-escape pattern where an attacker places a symbolic link (or hardlink) inside a sandboxed directory, pointing to a target outside the directory. Subsequent operations against the link's source path resolve transparently to the link's target, bypassing application-layer boundary checks that inspected only the source path string. The pattern is decades old in classical security and was re-instantiated in agentic AI by CVE-2025-53109 ("EscapeRoute") in Anthropic's official Filesystem MCP server, analysed in detail in the EscapeRoute writeup.

The attack works because the validation code in the application checks the source path string, while the kernel resolves the path through whatever the symlink points at. An application that says "this path starts with my configured root, so it's safe" approves the operation; the kernel then operates on the link's target, which can be anywhere on the filesystem the application's process has UID-level access to. The two checks diverge whenever a symlink is involved, and the application has no way to make the kernel honour its application-layer boundary unless it explicitly resolves the path before the check.

Why Symlink-Following Is Hard to Defend at Application Layer

Three properties make symlink-following bypass hard to defend in application code. Symlink semantics are OS-defined, not application-defined. The kernel chooses how to resolve symlinks; the application has no override mechanism beyond explicit realpath calls. Symlink chains can be long. A → B → C → D where only D is outside the root may not be visible to a single-step check. TOCTOU races compound the problem. Even if the application calls realpath and validates the result, an attacker who can write to the directory between the check and the operation can swap the symlink to a new target before the operation happens.

Defensive Patterns

The structurally sound defence is to operate at the kernel layer rather than re-implementing path resolution in application code. On Linux, openat2 with RESOLVE_BENEATH and/or RESOLVE_NO_SYMLINKS flags causes the kernel to reject any path resolution that crosses the configured root or follows a symlink — without the application needing to inspect the result. Mount namespaces, chroot, and container-level path constraints achieve similar guarantees by restricting which paths the kernel can resolve at all.

For application code that cannot use kernel-level constraints, the conservative defence is to refuse all symlinks: resolve the requested path, walk every component, and reject if any component is a symlink whose target is outside the configured root. This is more expensive than a naive prefix check and still vulnerable to TOCTOU, but closes the most common exploit primitives.

For deeper guidance on filesystem-MCP-specific defence, see the EscapeRoute case study and the MCP Security Audit service description.