My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale

What it is

MCP-FSD is a detection framework for "filesystem capability laundering" in local stdio MCP servers. A tool's declared contract (name, description, schema) looks narrow, but the server process runs with the user's ambient filesystem permissions. Client approval of the call therefore does not constrain which files the tool can reach. The paper formalizes this as Reach(t) ⊄ B(t;d): everything attacker-steerable arguments can touch exceeds the permissions the contract and deployment justify. It documents two CVEs in Anthropic's Git MCP Server, one of which is CVE-2026-27735 (the git_add case below). It also cites CVE-2025-53110 in the Filesystem MCP Server.

How it works

The paper analyzes the problem at three layers:

• L1, server category: a filesystem capability flag on a server with a non-filesystem primary_type. This is a coarse screen only.
• L2, per-tool contract gap: for example, git_add stages an out-of-repo file, and a later git_diff_staged returns its contents. This is CVE-2026-27735.
• L3, defeated path check: the Filesystem MCP Server's string-prefix check admitted sibling directories sharing the allowed prefix (CVE-2025-53110).

The pipeline:

1. Static screening. An LLM flags tool registrations, handlers and path parameters. Findings are emitted as SARIF under PT-001 (missing validation), PT-002 (prefix-match), PT-003 (URL traversal), PT-004 (symlink TOCTOU) and PT-005 (blacklist filter). Four filters then narrow the candidates: - M1 ranks findings tagged to MCP tools. - M2 finds path-shaped schema parameters. - M3 requires a plausible file-content return, so a line count doesn't qualify. - M4 keeps only stdio-runnable servers.
2. Boundary inference. An LLM drafts a least-privilege policy from the launch config, schema and description. The policy is extended to cover runtime needs found in the source. Read-write covers the working directory. Read-only covers the server binary, dependencies and system roots.
3. Fixtures. A credential fixture is planted outside every allow scope and a benign marker inside it.
4. Payloads and validation. An LLM generates schema-valid payloads, seeded with published traversal exemplars. For structured inputs it wraps the target in a format-valid container. Three-case dynamic validation measures exploitability, benign operability and sandbox containment. The main oracle is the fixture's contents appearing verbatim in the MCP response.

flowchart LR
  A[Injected content] --> B[Agent builds tool call]
  B --> C{Client approval}
  C -->|admits declared args| D[Server process, ambient FS access]
  D --> E[Out-of-scope file read]
  E --> F[Contents in tool response]
  S[Sandbox policy] -.cuts.-> D

Preconditions / Affected

• Local stdio MCP servers run as separate processes with the user's filesystem permissions and no per-tool path restriction.
• An adversary can influence a tool argument through content the agent ingests.
• The server has host permission to read the target file.
• The response must carry file contents. Metadata-only responses don't count as disclosure.

Measured prevalence:

• 787 of 4,806 triaged servers (16.4%) have a filesystem capability flag without a FileSystem label.
• 150 instances were dynamically confirmed under the tested sandbox policies.
• 13 additional findings were selected for disclosure, yielding 13 advisories.

What to do

The captured text ends mid-method, so no mitigations or patched versions are available from it. The page implies these checks:

• Audit servers for tools that pass path-like arguments to libraries (such as GitPython) without a containment check.
• Treat approval of a tool call as not limiting filesystem scope. Run local servers under an explicit sandbox policy.
• Use a path containment check that is not a string prefix.

Caveats

• The boundary is an LLM-inferred hypothesis, not ground truth. The authors discuss its limits in §6.2, which is not in the fetched text.
• The 150 confirmations hold only under the tested sandbox policies.
• L1 category mismatch is a screening signal, not proof, since non-filesystem servers often legitimately persist data locally.
• Emissions and confirmed instances use different counting units.
• Hosted services were excluded because their runtime cannot be reproduced.
• Static scanning does not analyze dependency internals.