A separate bug affected writes, not the read_text_file path. In a same-device move, the destination was anchored to its approved directory, but the source pathname was reopened at rename time. An attacker who swapped the source parent between validation and rename could cause a file from outside the allowed tree to be moved into it. Once moved, normal MCP…
Inspect the ClaimsCase · DiggingBeagle record
MCP filesystem move_file could move a protected outside source through a renamed parent
A separate bug affected writes, not the read_text_file path. In a same-device move, the destination was anchored to its approved directory, but the source pathname was reopened at rename time. An attacker who swapped the source parent between validation and rename could cause a file from outside the allowed tree to be moved into it.
Public disclosure: Nov 11, 2026
Scope
Local cooperating swapper and same-device move on an affected filesystem MCP server, with no identified deployment victim.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade C
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The upstream GHSA describes a source-path rename race with admitted timing and platform uncertainties; patched versions are reported, not independently audited here. An impact band is not assigned because the available Claims do not establish a comparable verified severity or quantified harm.
Assessed Nov 12, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-R239-031-CORE · MCP filesystem move_file same-device rename races unpinned source, importing protected outside file
At a glance
The observed effect is limited to the study or disclosed setting; deployment and independent impact remain unestablished.
Read the implicationsWindows behavior, race reliability and whether every file class was reachable were not established.
Limits and uncertaintyFull account
A separate bug affected writes, not the read_text_file path. In a same-device move, the destination was anchored to its approved directory, but the source pathname was reopened at rename time. An attacker who swapped the source parent between validation and rename could cause a file from outside the allowed tree to be moved into it.
Once moved, normal MCP read tools could access the newly relocated file; the original outside path was also changed. The advisory describes controlled reproduction against the pre-2.3.0 implementation and acknowledges timing and platform limitations. This is not the same root cause or operation as the related read race even though both involve path resolution.
This bug affects the source side of rename, whereas the companion read bug opens a path after validation without pinning it. Both require a race-capable local actor and sufficient MCP process permissions; neither is proof of an arbitrary remote read. Moving the source also produces an integrity consequence absent from a read-only disclosure.
Mechanism and trust boundary
- 01
An attacker with local access repeatedly swaps an approved source directory for an outside-pointing symlink.
- 02
The move tool validates the paths but uses a non-anchored absolute source pathname for same-device rename.
- 03
The server may relocate an outside file into its allowed root, enabling later reads and changing the original path.
Claims & evidence
CLM-R239-031-COREGHSA-7m4x-rv66-mxhh describes a same-device move_file race that could move an outside file into an allowed directory because the source pathname was not pinned.supported
Basis: reported finding
- supportsMCP filesystem move_file same-device rename races unpinned source, importing protected outside fileprimary disclosure
Security advisory, source-parent swap test and patched-version listing
Implications
The observed effect is limited to the study or disclosed setting; deployment and independent impact remain unestablished.
Controls and mitigations
- Pin both source and destination directory objects, test same-device and cross-device paths and install server-filesystem 2.3.0.
Unknowns and contradictions
- Windows behavior, race reliability and whether every file class was reachable were not established.
Sources and citation
Material revision history
- Nov 12, 2026 · Published version · first publication · revision 241