Imagine you hire a locksmith to copy your front-door key. You watch them cut the key, hand it over, pay them — normal transaction. But because you let them into your house to measure the lock, they also quietly copied the key to your filing cabinet, your safe, and your medicine drawer. That's filesystem capability laundering in the Model Context Protocol ecosystem: a tool declares it does one thing, but the permissions it actually receives let it do far more, and an attacker who controls the tool's arguments can redirect it to sensitive files the user never intended to expose. The committed claim: MCP servers routinely receive filesystem permissions far exceeding their declared contract, and this gap is systematically exploitable at scale. The authors call this "filesystem capability laundering" — a tool's stated purpose (say, a database query tool) launders its way into filesystem read/write capabilities that were never part of its advertised contract. This isn't a single bug report. It's a vulnerability class analysis across 21,097 MCP servers scraped from nine registries. The method, called MCP-FSD, works in three layers. L1 screens server categories — does a "weather" server have any business touching your filesystem? L2 analyzes per-tool contracts to infer least-privilege boundaries. L3 checks whether existing path-validation guards can be bypassed. The dynamic validation is the sharp part: the authors plant credential fixtures (fake SSH keys, API tokens, cloud credentials) outside the inferred privilege boundary, then run paired executions — one that should succeed within scope, one that shouldn't — to confirm real exploitability. Of 4,806 servers that survived initial triage, 787 (16.4%) had filesystem capabilities despite being classified as non-filesystem tools. Dynamic three-case testing confirmed 150 instances where an attacker-steered argument could actually reach the planted credentials. The ladder here is interesting because there isn't a clean prior benchmark to beat — this is the first systematic measurement of MCP permission hygiene at this scale. The closest prior art is ad-hoc vulnerability disclosure against individual MCP servers, not a methodological framework for auditing the entire ecosystem. The 16.4% incidence rate and 150 confirmed vulnerable instances are the new baseline numbers the field will cite. The coordinated disclosure produced 13 security advisories including two CVEs (in Anthropic's own Git MCP Server), which gives the work immediate practical teeth. The integrity picture is mixed in instructive ways. The dynamic validation with planted credential fixtures is a genuinely clever experimental design — it converts a static analysis claim into a behavioral confirmation. But the sandbox policies tested are specific configurations, and the paper's 150 confirmed instances are under those specific policies. Different sandbox configurations could yield different numbers. The nine registries provide good coverage but aren't exhaustive. The authors disclosed responsibly and got real CVEs, which is the strongest form of external validation in security research — the vendors agreed these were real bugs. The milestone question is about the MCP ecosystem's maturity curve. Right now, MCP is in its "wildcat" phase — servers are proliferating faster than security hygiene. The paper establishes that ~16% of servers have undeclared capabilities. The next number to watch is what that percentage looks like after the ecosystem absorbs this paper's findings and whether registries adopt mandatory least-privilege declarations. If the number doesn't drop below 5% within 18 months, MCP's permission model needs architectural redesign, not just better auditing. The obvious experiment the authors didn't run: testing against MCP clients with adaptive permission scoping (where the client dynamically restricts filesystem access based on the tool's declared contract rather than granting blanket host permissions). The paper notes that current deployments grant broad permissions, but some clients are beginning to implement tighter sandboxing. The honest read is (a) — the infrastructure for that experiment doesn't exist at scale yet, not that the authors avoided it.
