al-ice.ai

Approval Is Not Enforcement: 21,097 MCP Servers Measured for Filesystem Escapes

AI Security Research by al-ice.ai Editorial

When you approve an MCP tool call, what exactly did you approve? A paper published 15 October 2026 — “My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale” (arXiv:2610.22301, Huang, Tang, Guan, Sun and He) — gives the uncomfortable answer: you approved the declared arguments, while the server process that runs the tool holds your ambient filesystem permissions and nobody enforces the difference. The authors name the resulting defect class filesystem capability laundering: attacker-steered arguments cause a tool to touch sensitive host files outside its declared contract, and the file bytes come back inside an ordinary, approved tool response.

The structural claim is the one to sit with. MCP supports client-provided filesystem roots, and tool definitions can carry behavioural annotations — but the specification delegates per-tool filesystem enforcement entirely to individual server implementations or host environments. The client’s approval prompt gates execution based on declared arguments; the spawned server process executes with whatever the user can read. Approval is a UI event. Enforcement would have to be a sandbox. In typical local deployments, it is not.

Three layers, one gap

The paper organises the gap into three layers. At L1, server-category screening, the authors compare inferred filesystem-capability flags against each server’s functional classification: a server filed under memory or code development that can touch the host filesystem is a coarse but telling mismatch. At L2, per-tool contract analysis, a narrow operation reaches beyond its scope — the signature example is git_add staging an out-of-repository file whose contents a later diff returns (CVE-2026-27735). At L3, defense bypass, an existing path check is defeated, as in the Filesystem MCP Server’s string-prefix check that admitted sibling directories sharing the allowed prefix (CVE-2025-53110). Path traversal in the harness is already documented — the paper cites Claude Code’s prefix-match bypass and symlink-following — but the server process is the softer target, because no harness check runs inside it at all.

To measure rather than assert, the authors built MCP-FSD (Filesystem Scope Detection): catalog servers across registries, discover each server’s tools inside per-repository sandboxes, screen with MCP-aware static filters, infer a least-privilege boundary per tool, plant credential fixtures outside that boundary, and validate with paired dynamic execution across three cases — exploitability, benign operability, and sandbox containment. The fixture design is the methodological point worth stealing: instead of arguing about what a tool should touch, they define the boundary, put secrets outside it, and watch what comes back in the response.

The numbers, and what survived contact with execution

Static screening across 21,097 MCP servers from nine registries found that 787 of 4,806 triaged servers (16.4%) exhibit filesystem capabilities despite non-filesystem functional classifications. That is the screening signal, not the vulnerability count — and the authors are honest about the difference, which is why the dynamic stage matters. Three-case validation confirmed 150 vulnerable instances under the tested sandbox policies, and coordinated disclosure of selected findings produced 13 security advisories. Two CVEs in Anthropic’s Git MCP server — unscoped repository creation in git_init (CVE-2025-68143) and path-traversal staging in git_add (CVE-2026-27735) — are documented as worked case studies, not new disclosures; both are older, patched issues, and this site has previously covered prompt-injection-reachable CVEs in that same server. The paper’s contribution is the class definition and the ecosystem measurement, not those two CVEs.

Two caveats before anyone cites the 16.4% figure loosely. First, the paper flags its own triage snapshot and selection bias: 4,806 servers triaged out of a 21,097 catalog is a funnel, and funnels have shapes. Second, “under tested sandbox policies” is doing load-bearing work in the 150-instance claim — containment results are relative to the policies tested, not a proof about all deployments. Neither caveat dents the central finding: the approval prompt is not a capability boundary, and one server in six in the triaged set carries filesystem reach its category label never advertised.

What defenders should take from this

First, sandbox the server process, not the prompt. Filesystem roots and per-tool path policies must be enforced on the process that touches files; a client-side approval dialog enforces nothing there. If your MCP deployment cannot state, per tool, which paths are reachable, you have the vulnerability class by construction. Second, treat tool arguments as untrusted input all the way down — the ToFu result from the same week showed attacker-dictated arguments breaking 253 tool bugs across six frameworks, and this paper shows where those arguments can go once inside. Third, run the paper’s fixture trick on your own estate: infer each tool’s least-privilege boundary, plant credentials outside it, and read your own responses. It is cheap, it needs no threat intel, and it converts an architectural suspicion into executable evidence — which is also, incidentally, how the authors got thirteen advisories out of a measurement study.

The through-line of this month’s MCP coverage is converging on a single sentence: the protocol authenticates the tool call and leaves everything after it to chance. The traversal that picked its own serializer and the SSRF pivots across five MCP servers are the same disease at different layers — declared contracts with unenforced boundaries. Laundering is simply its filesystem form, now with a name, a detector, and a five-digit denominator.

Our verification was read-only. The paper title, author list and affiliations, arXiv identifier and version, publication date, CC BY 4.0 licence, threat model, L1/L2/L3 framing, MCP-FSD design, corpus and triage counts, validation and disclosure figures, and the three cited CVEs were read first-hand from the arXiv abstract and HTML full text of 2610.22301. The December 2025 and February 2026 dates for the two Git MCP CVEs come from the authors’ companion write-ups; both post-date this site’s earlier Git MCP server coverage, which is linked above. No MCP server was executed or probed. Brave Search was used for discovery only.

Sources: