GHSA-rr55-jp92-8wp2: Path Traversal
Summary 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.
Affected tools The shared getProjectPath() chokepoint (feeding the .faf tools) and the general-purpose fafread / fafwrite 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 fafwrite could write outside the project.
Impact 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/idrsa), cloud credentials (~/.aws/credentials), .env files, source, /etc/passwd; and fafwrite 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).
Patches 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 (fafread / fafwrite) are confined to the project root (cwd + system temp; override with FAFALLOWEDROOTS). - 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).
Workarounds If you cannot upgrade immediately, run the server only against trusted local projects, and set FAFALLOWEDROOTS (patched versions) to a single project directory for a hard directory boundary.
Credits 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/claude-faf-mcpto a version that resolves this vulnerability.Fixed in 5.7.2 - Upgrade
Upgrade
claude-faf-mcpto a version that resolves this vulnerability.Fixed in 5.7.2 - Configuration
If you cannot upgrade immediately, run the server only against trusted local projects and set FAF_ALLOWED_ROOTS (in patched versions) to a single project directory to enforce a hard directory boundary.
claude-faf-mcp server FAF_ALLOWED_ROOTS = single project directory - Compensating control
Run the server only against trusted local projects (avoid processing attacker-controlled content that could prompt-inject tool calls with a crafted path).
Event History
Frequently Asked Questions
Who is exposed to this issue?
Any deployment where an untrusted MCP client can invoke the affected tools is exposed. This also includes deployments where an LLM can be prompt-injected through attacker-controlled web pages, READMEs, tickets, or .faf content into making tool calls.
What access does an attacker need?
The attacker needs a way to cause an affected MCP tool call with a chosen path argument. No authentication, user interaction, or filesystem access beyond the permissions of the server process is described as necessary.
What limits the impact if the issue is exploited?
Operating-system file permissions are the remaining limit. An attacker can read or write only files that the claude-faf-mcp server process itself is permitted to access.
What can be done if patching cannot happen immediately?
Reduce the filesystem permissions of the process running claude-faf-mcp, since those permissions determine which files an exploit can access. Avoid allowing untrusted clients or prompt-influenced content to trigger its file-related MCP tools.