Summary
faf-mcp has an arbitrary local file read/write via unconfined path argument in FAF tools
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 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.
Workarounds
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.
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).
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; 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).
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
GHSA-J4R7-8PH4-43G3 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.1.3); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 2.1.3 by confining every caller-supplied path before any filesystem access (safe-path.ts):
- Reads are restricted to
.faf/.fafmcontext 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 withFAF_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 [email protected] (or npx faf-mcp).
Frequently Asked Questions
- What is GHSA-J4R7-8PH4-43G3? GHSA-J4R7-8PH4-43G3 is a high-severity path traversal vulnerability in faf-mcp (npm), affecting versions <= 2.1.2. It is fixed in 2.1.3. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- How severe is GHSA-J4R7-8PH4-43G3? GHSA-J4R7-8PH4-43G3 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of faf-mcp are affected by GHSA-J4R7-8PH4-43G3? faf-mcp (npm) versions <= 2.1.2 is affected.
- Is there a fix for GHSA-J4R7-8PH4-43G3? Yes. GHSA-J4R7-8PH4-43G3 is fixed in 2.1.3. Upgrade to this version or later.
- Is GHSA-J4R7-8PH4-43G3 exploitable, and should I be worried? Whether GHSA-J4R7-8PH4-43G3 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-J4R7-8PH4-43G3 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-J4R7-8PH4-43G3? Upgrade
faf-mcpto 2.1.3 or later.