grok-faf-mcp has an arbitrary local file read via unconfined `path` argument in FAF tools

Summary

Several grok-faf-mcp MCP tools accept a caller-controlled path argument and resolve it (~ expansion + path.resolve()) straight into a filesystem read 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 files outside the intended .faf project context. The only remaining limit is OS file permissions.

Affected tools

refresh_faf, faf_score, faf_get_orchestration_policy, refresh_blend (and the shared getProjectPath() chokepoint feeding the .faf tools), plus the general-purpose faf_read / faf_write file tools (denylist-only; an absolute path still reached home-directory secrets, and faf_write could write outside the project). refresh_faf echoes the file contents verbatim back to the caller as "fresh DNA"; faf_get_orchestration_policy reflects values parsed out of the attacker-chosen file and echoes the resolved absolute path — confirming the read.

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/id_rsa), cloud credentials (~/.aws/credentials), .env files, source, /etc/passwd. 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 is reached by a crafted tool call (e.g. a prompt-injected agent processing attacker-controlled content).

Patches

Fixed in 1.5.3 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.