Source-linked AI summary
My Credentials, Please: Detecting Filesystem Capability Laundering in MCP Servers at Scale
Zeqian Huang, Mingyue Tang, Aonan Guan, Qiming Sun, Pengzhou He
TL;DR
MCP tool approval does not restrict the ambient filesystem permissions of locally launched servers, leaving a gap between a tool’s declared contract and its effects. The paper builds MCP-FSD to screen servers and dynamically validate tool access against inferred least-privilege boundaries. It finds filesystem capability signals in 16.4% of triaged servers and confirms 150 vulnerable instances under tested policies.
Problem
MCP delegates per-tool filesystem enforcement to server implementations or host environments, while locally launched servers can retain ambient filesystem permissions despite client-side approval.
Source: §1 · p. 2Method
MCP-FSD catalogs MCP servers, screens candidates with MCP-aware static filters, and dynamically validates them against inferred least-privilege boundaries.
Source: §1 · p. 2Results
787 of 4,806 triaged servers (16.4%) had filesystem capability flags without a FileSystem category label, and dynamic validation yielded 150 adjudicated instances under tested policies.
Source: §1 · p. 2Takeaways & Limitations
The findings demonstrate the necessity of ecosystem-scale registry screening and explicit, runtime-enforced per-tool filesystem contracts.
Source: §8 · p. 18Dynamic validation may miss violations whose effects do not appear in responses or require runtime preconditions the harness does not reproduce, and inferred-boundary accuracy was not measured.
Source: §6.2 · p. 16
Abstract
from arXiv · showhide
The Model Context Protocol (MCP) standardizes how AI agents invoke external tools. MCP servers expose tools through a declared contract consisting of a name, description, and argument schema. In typical local deployments, client-side approval of a tool call grants the underlying server process broad host filesystem permissions rather than restricting it to the declared operation. We study the resulting vulnerability class, filesystem capability laundering, where attacker-steered arguments cause a tool to access sensitive host files outside its declared contract and deployment scope. We analyze this capability gap across three layers: server-category screening (L1), per-tool contract analysis (L2), and bypassable path-validation checks (L3). We design MCP-FSD to catalog MCP servers, infer least-privilege boundaries per tool, plant credential fixtures outside those boundaries, and evaluate exploitability and sandbox containment via paired dynamic execution. Across 21,097 MCP servers from nine registries, 787 of 4,806 triaged servers (16.4%) exhibit filesystem capabilities despite non-filesystem functional classifications. Dynamic three-case validation confirms 150 vulnerable instances under tested sandbox policies. Coordinated disclosure yielded 13 security advisories, including two CVEs in Anthropic's Git MCP Server.
1 Introduction
MCP tool approval does not enforce per-tool filesystem limits on locally launched server processes, creating a gap that attacker-steered arguments can exploit. The paper introduces MCP-FSD to screen this gap and validate out-of-scope filesystem access across MCP servers.
1 Introduction
- Client approval gates execution based on declared arguments, while locally launched servers retain ambient host filesystem permissions that can expose credentials through ordinary tool output.The paper calls this vulnerability class filesystem capability laundering: exercising an out-of-scope capability under an innocuous tool contract.Source: §1 · p. 2
- The paper examines the gap through category mismatches (L1), narrow tool operations that reach beyond intended scope (L2), and bypassable path checks (L3).Examples include staging an out-of-repository file for later disclosure through diff and a string-prefix check admitting sibling directories.Source: §1 · p. 2
- 787 of 4,806 triaged servers (16.4%) had filesystem capability flags without a FileSystem category label, and dynamic validation yielded 150 adjudicated instances under tested policies.The study catalogs 21,097 servers from nine registries.Source: §1 · pp. 2–3
- MCP-FSD catalogs servers, discovers tools in per-repository sandboxes, screens candidates with MCP-aware static filters, and dynamically validates them against inferred least-privilege boundaries.The framework evaluates exploitability, benign operability, and sandbox containment across three dynamic validation cases.Source: §1 · p. 2
- The paper characterizes how attacker-influenced tool arguments can expose filesystem capabilities beyond a tool’s contract and deployment scope.Its research questions cover screening evidence, dynamic-validation outcomes, disclosure, distributions across language, registry, and tool category, and format-wrapped payloads.Source: §1 · pp. 2–3
2 Background and Threat Model
In local stdio deployments, approval of a tool call does not restrict the server process’s ambient filesystem access, so attacker-steered arguments can cause effects beyond a tool’s contract and deployment scope. The paper formalizes this gap and identifies challenges in inferring boundaries and validating candidate violations across diverse MCP servers.
2.1 Threat Model
- Local server processes can use ambient host filesystem permissions even when client approval gates a call, allowing attacker-influenced arguments to steer a benign-looking tool toward out-of-scope files.The evaluation assumes the tested call is issued and the server can access the target; arbitrary server-code modification and OS-sandbox compromise are outside its model.Source: §2.1 · p. 3
2.2 Filesystem Capability Laundering
- Filesystem capability laundering occurs when attacker-steered arguments produce filesystem effects beyond the tool’s contract and deployment scope while surrounding controls fail to constrain them.The paper separates category/capability screening (L1), per-tool contract/effect gaps (L2), and defeated implementation controls (L3); these layers can overlap.Source: §2.2 · p. 3
2.3 Problem Formalization
- The formalization compares the filesystem effects reachable through adversarial arguments with permissions justified by the tool contract and fixed deployment context.A disclosure witness additionally requires an out-of-scope read whose file contents appear in the tool response; an explicitly stated call sequence can be assessed using combined effects and responses.Source: §2.3 · pp. 4–5
2.4 Problem Statement and Challenges
- MCP servers span registries, languages, and packaging conventions, while path parameters alone do not establish which locations a tool is authorized to access.Boundary inference therefore combines the declared contract with deployment evidence such as a selected repository root.Source: §2.4 · p. 5
- Library-mediated operations require source review to identify calls and dynamic testing to determine whether file contents reach an MCP response.Inputs may be paths, file lists, or structured documents with references, so payloads must remain schema-valid to reach the filesystem operation.Source: §2.4 · p. 5
- Connecting filesystem analysis to MCP requires linking candidate findings to callable tools, their schemas, response construction, and stdio execution.MCP-FSD uses these links to produce reproducible calls.Source: §2.4 · pp. 5–6
3 MCP-FSD Design
MCP-FSD measures and triages MCP servers, then validates candidates against inferred per-tool least-privilege boundaries. Its validation combines schema-aware payload generation with unconfined, benign-in-sandbox, and malicious-in-sandbox executions.
3 MCP-FSD Design
- MCP-FSD uses a measurement pass to collect servers, discover tools and schemas, and triage filesystem capabilities, followed by validation using static filters, inferred boundaries, and dynamic tests.The disclosure oracle primarily checks whether planted fixture contents appear in the MCP response.Source: §3 · p. 6
3.1 Static Screening
- Four MCP-aware filters prioritize candidates by tool association, path-shaped schema parameters, plausible file-content responses, and local stdio executability.The scan can flag visible library calls without reconstructing dependency internals; emissions at fix sites and dynamically confirmed instances are distinct counting units.Source: §3.1 · p. 7
3.2 Boundary Inference Algorithm
- Boundary inference derives each tool’s least-privilege scope from its operation, allowing working-directory writes and read-only access to runtime dependencies.The credential fixture must lie outside every allow scope, while a benign marker inside the working scope checks that intended operations remain possible.Source: §3.2 · pp. 7–8
3.3 Payload Generation and Dynamic Three-Case Validation
- For each path-shaped parameter, payload generation targets a fixed out-of-scope credential fixture and uses schema-valid argument forms, including wrapped inputs for structured-file tools.The argument form varies while the target stays fixed, and the test state is reset before replay with and without the sandbox.Source: §3.3 · pp. 8–9
- Three-case validation tests malicious disclosure without a sandbox, benign operation with the sandbox, and replay of the malicious call with the sandbox to check containment.Together, the cases separate exploitability from containment; containment may be explicit when denial is exposed or silent when the response is empty or non-disclosing.Source: §3.3 · p. 9
4 Evaluation
MCP-FSD screens MCP servers for filesystem-scope mismatches, then dynamically tests candidates and reports confirmed instances and disclosure outcomes. The evaluation also characterizes the selected corpus, violation distribution, and payload forms.
4.1 Experiment Setup
- Static analysis returned results for 4,292 servers and flagged 2,818, or 13.4% of the 21,097-server catalog, for potential vulnerabilities.MCP-FSD’s dynamic validation ran candidates in the nono v0.43.0 macOS Seatbelt sandbox.Source: §4.1 · p. 10
- Only 7,222 of 21,097 catalogued servers reached measurement; the post-measurement corpus was 97% Node and Python, with pulsemcp supplying 84% of startups.The authors characterize prevalence estimates and registry comparisons as describing this locally runnable open-source corpus, not a uniform distribution across ecosystems.Source: §4.1 · p. 10
4.2 RQ1: Screening Signals and Evidence
- Among tools lacking a FileSystem category classification, 16.4% exhibit at least one filesystem capability flag; because routine persistence need not violate a tool’s contract and catalog-wide external ground-truth labels are absent, this mismatch is a coarse initial screening signal, not a definitive violation metric.Source: §4.2 · p. 11
- Across 10,304 static emissions, defense-bypass rules PT-002–PT-005 accounted for 61.6%, versus 36.4% for PT-001 missing validation.Static URL-traversal emissions may not disclose local files, so static counts are distinct from dynamic outcomes.Source: §4.2 · p. 11, Figure 4 · p. 11
4.3 RQ2: Confirmed Instances
- 150 instances passed three-case dynamic adjudication; 136 relied on exact credential-marker matching, while 14 used other transcript evidence.The other evidence included write side effects, response-shape changes, or external-CLI outputs.Source: §4.3 · pp. 11–12
4.4 RQ3: Disclosed Outcomes
- 13 findings were reported, including two CVEs in Anthropic’s Git MCP Server; git_add received full dynamic validation, while git_init was a static, indirect finding.Both CVEs were patched upstream.Source: §4.4 · p. 12
4.5 RQ4: Violation Distribution
- Node files made up 54.3% of emissions and Python 42.6%; Python led PT-001, while Node led every bypass-style rule at 57%–63%.The authors identify default allowlist helpers for Python and standardized path-containment primitives for TypeScript as distinct remediation paths.Source: §4.5 · pp. 12–13, Figure 5 · p. 14
4.6 RQ5: Payload Forms
- 144 of 150 confirmed instances (96.0%) used bare traversal paths, while 6 (4.0%) required format-valid containers.Format-valid fixtures let structured-input tools accept a payload before their filesystem calls are tested.Source: §4.6 · p. 13
5 Case Studies
The Git MCP Server cases show how caller-selected paths can exceed workspace or repository scope through different operations. In git_init, an out-of-scope directory can become a repository that later Git calls read; in git_add, traversal paths can stage external files.
5.1 Case 1 (L2): Unscoped Repository Creation in git_init (CVE-2025-68143)
- git_init accepts a caller-supplied repo_path without checking workspace containment, so a sensitive directory can become a repository whose later Git-tool diffs expose files such as SSH keys.The issue was assigned CVE-2025-68143, and the fix removed git_init from the server.Source: §5.1 · p. 14
- git_add can stage paths containing ../ because the handler does not enforce repository containment; the staged files can then be exposed through a diff or sent in a later push.The pre-patch three-case validation returned planted credentials in an unsandboxed run, allowed a benign in-scope call under sandboxing, and denied the malicious call with EPERM.Source: §5.2 · p. 15
5.3 Synthesis
- Containment must be checked at different points: git_init’s creation target must remain in the deployment workspace, while every git_add path must remain inside the existing repository.A later repository-root check can miss git_init’s earlier workspace violation, since subsequent calls can stage and display files after the sensitive directory becomes a repository.Source: §5.3 · p. 15
6 Discussion
The discussion proposes runtime and protocol-level ways to enforce per-tool filesystem scope, while emphasizing that validation results are bounded by installation, execution, and boundary-inference limits. It also describes the controlled, synthetic-fixture setting used for responsible disclosure.
6.1 Mitigations
- MCP-FSD’s three-case validation supports OS process isolation as a way to enforce least-privilege boundaries without disrupting benign tool functionality.The discussion also proposes canonical-path containment and schema validation at L3, an SDK containment helper, and a per-tool fs_scope field at L2; inferred policies require review against deployment requirements.Source: §6.1 · p. 16
6.2 Limitations
- The pipeline validates only servers it can install and run, and dynamic results depend on successful startup and selected runtime configurations.Validation may also miss effects absent from tool responses or runtime preconditions the harness does not reproduce.Source: §6.2 · p. 16
- The study does not measure inferred-boundary accuracy, so overly restrictive policies may flag legitimate access while overly permissive ones may miss violations.It also does not systematically measure unauthorized file creation, modification, or deletion, and future benchmarks should quantify boundary-inference precision and recall.Source: §6.2 · p. 16
- A targeted mcp-architect case shows that filesystem-state evidence can reveal an unauthorized write even when tool responses return no file contents.An unsandboxed invocation wrote a sentinel outside the allowed storage directory; sandboxed replay was blocked with EPERM.Source: §6.2 · pp. 16–17
- Validation covers selected tools and stated call sequences, not systematic cross-tool chains, and enforcement strength depends on the sandbox backend.LLM-generated triage labels, static-rule families, and boundary-policy drafts inherit model error modes; their accuracy remains unmeasured.Source: §6.2 · p. 17
6.3 Ethical Considerations
- The study uses controlled installations and synthetic fixture credentials, resets between cases, and omits the test sandbox from PoC 1.The Git MCP cases were reported to the affected vendor and both received CVE assignments.Source: §6.3 · p. 17
7 Related Work
Related work examines MCP security, agent attacks, and filesystem-flaw detection, but the paper distinguishes its focus on attacker-steered filesystem effects tested against inferred per-tool scopes. It also emphasizes that description-code agreement, data reaching a response, and authorization against a policy answer different questions.
MCP security and filesystem detection
- MCP-FSD tests filesystem effects triggered by attacker-controlled arguments against an inferred policy for each tool, unlike DCIChecker’s analysis of description-code inconsistencies [35].The related-work comparison situates MCP-FSD among MCP security studies [41] [38] [37] [35] [17] and filesystem-flaw detectors [20].Source: §7 · p. 17
- MCP-FSD combines static screening with native-host dynamic three-case replay against inferred per-tool scopes, rather than WASI sandboxing and output matching [37].Unlike mobile analyzers such as PathSentinel [20], it infers least-privilege boundaries from tool descriptions and deployment configurations.Source: §7 · p. 17
Agent security, prompt injection, and isolation
- Description-code agreement, file-to-output flow, and authorization are distinct questions: a diff can return file bytes while repository-root policy determines whether access exceeded scope.MCP-FSD records the source candidate, policy, and execution transcripts together; related work also spans harmful tool use, agent backdoors, instruction-following attacks and defenses [32], and OS containment [18].Source: §7 · pp. 17–18
8 Conclusion
The conclusion frames filesystem capability laundering as a gap between client-side approval and unconfined server execution. MCP-FSD combines ecosystem-scale screening, inferred per-tool boundaries, and dynamic validation, while Git-server vulnerabilities illustrate credential exposure through ordinary repository operations.
8 Conclusion
- Across 21,097 cataloged servers, MCP-FSD couples static screening, inferred least-privilege boundaries, and dynamic three-case validation to address filesystem capability laundering.The conclusion cites real-world repository creation and staging flaws in Anthropic’s Git server as examples of ordinary tool interactions leaking sensitive host credentials.Source: §8 · p. 18