claude-faf-mcp MCP tools accept a caller-controlled path argument and resolve it (~ expansion + path.resolve()) straight into a filesystem read/write without confining it to a trusted project directory. An absolute path or ../ traversal is resolved and used as-is, so the server process can be made to read — and, via the file tools, write — files outside the intended .faf project context. The only remaining limit is OS file permissions.

The shared getProjectPath() chokepoint (feeding the .faf tools) and the general-purpose faf read / faf write file tools resolved a caller path straight into a read/write with no confinement (denylist-only); an absolute path still reached home-directory secrets, and faf write could write outside the project.

An MCP client — or an LLM prompt-injected via attacker-controlled content (a web page, README, ticket, or .faf) into issuing a tool call — can read any file the server process can read: SSH keys (~/.ssh/id rsa), cloud credentials (~/.aws/credentials), .env files, source, /etc/passwd; and faf write could write outside the project. This is a sensitive-information-disclosure (CWE-200) primitive that far exceeds the declared .faf project-context scope. The server runs over stdio, so the read/write is reached by a crafted tool call (e.g. a prompt-injected agent processing attacker-controlled content).

Fixed in 5.7.2 by confining every caller-supplied path before any filesystem access (safe-path.ts):

Upgrade: npm install -g claude-faf-mcp@5.7.2 (or one-click .mcpb install).

If you cannot upgrade immediately, run the server only against trusted local projects, and set FAF ALLOWED ROOTS (patched versions) to a single project directory for a hard directory boundary.

Identified by the maintainers during a sibling-server audit prompted by the coordinated disclosure of the same class of issue in grok-faf-mcp by Zhihao Zhang (Worcester Polytechnic Institute).