The report
A file tool can validate a pathname, receive permission to proceed and still operate on a different filesystem object by the time it opens or renames the file. Two new advisories for the reference MCP filesystem server demonstrate this timing problem with different effects. Both were fixed in version 2.3.0, and both require more attacker access than an anonymous network request.
Read: the approved path changed before opening
In the read-side advisory, validatePath resolves a file within an allowed directory, but the subsequent read opens the pathname again. A cooperating local attacker can replace a writable parent directory with a symlink between those operations. The researchers reproduced a forbidden-file read in a two-user Linux setup where the attacker could not directly read the target, while the MCP process had sufficient privileges to do so. The read-race Case preserves the constraints: a writable parent, known target path, server-side permission and a successful race.
Move: the destination was anchored, the source was not
The move-side advisory concerns a same-device rename after both paths had been validated. Its destination used an anchored directory operation, but its source was still an absolute pathname resolved again during rename. By swapping the approved source parent, the attacker could move a readable outside file into the permitted tree, where normal file tools could then access it. This also changes the outside location by removing the original file; it is not just a confidentiality outcome. The move-race Case retains the narrower reproduction status and unresolved platform behavior.
Version 2.3.0 is listed as patched for both paths. The important test is object identity at effect time, not only a successful realpath check before effect. The advisories are separate vulnerabilities with distinct filesystem actions, prerequisites and integrity consequences. Neither publication provides evidence of a production victim.