Survey of filesystem MCP servers: how the "sandboxed filesystem" boundary is enforced (one breach, four defended-by-design)
Survey finds one filesystem MCP server vulnerable to a symlink-based sandbox escape while four others are defended by design.
A survey of five filesystem MCP servers assessed how each enforces its path-confinement boundary against symlink escapes in recursive directory walkers. The iceener/files-stdio-mcp-server is vulnerable to a read-side sandbox escape. The other four are defended by design or make no confinement claim. The author describes the vulnerability class as small but real.
- One of five surveyed filesystem MCP servers allows a read-side sandbox escape via symlinks.
- Boundary enforcement was tested against symlink escapes in recursive directory walkers.
- Four servers are defended by design or make no confinement claim.
- Vendors
- MCP
- Products
- iceener/files-stdio-mcp-server
From the original article
Posted by Eve on Sep 09 Summary ======= I surveyed five filesystem MCP servers that operate on a host filesystem and assessed how each enforces its "only these paths are available" boundary, specifically against a symlink escape in a recursive directory walker. One (iceener/files-stdio-mcp-server) is vulnerable to a read-side sandbox escape; the other four are defended by design (or make no confinement claim).
seclists.org
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.