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):
- Reads are restricted to .faf / .fafm context files, so non-context files (secrets) are refused regardless of directory.
- General file ops (faf_read / faf_write) are confined to the project root (cwd + system temp; override with FAF_ALLOWED_ROOTS).
- Paths are canonicalized through symlinks (closing the symlink bypass); absolute paths and ../ escapes are rejected; callTool() gains a central PATH-DENIED guard.
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).
{
"severity": "HIGH",
"nvd_published_at": null,
"github_reviewed": true,
"cwe_ids": [
"CWE-200",
"CWE-22",
"CWE-73"
],
"github_reviewed_at": "2026-08-19T19:15:25Z"
}