GHSA-RR55-JP92-8WP2
Vulnerability from github – Published: 2026-08-19 19:15 – Updated: 2026-08-19 19:15Summary
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 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.
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).
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 (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).
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).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.7.1"
},
"package": {
"ecosystem": "npm",
"name": "claude-faf-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T19:15:25Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`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 \u2014 and, via the file tools, write \u2014 files outside the intended `.faf` project context. The only remaining limit is OS file permissions.\n\n### Affected tools\nThe 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.\n\n### Impact\nAn MCP client \u2014 or an LLM prompt-injected via attacker-controlled content (a web page, README, ticket, or `.faf`) into issuing a tool call \u2014 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).\n\n### Patches\nFixed in **5.7.2** by confining every caller-supplied `path` before any filesystem access (`safe-path.ts`):\n- Reads are restricted to `.faf` / `.fafm` context files, so non-context files (secrets) are refused regardless of directory.\n- General file ops (`faf_read` / `faf_write`) are confined to the project root (cwd + system temp; override with `FAF_ALLOWED_ROOTS`).\n- Paths are canonicalized through symlinks (closing the symlink bypass); absolute paths and `../` escapes are rejected; `callTool()` gains a central PATH-DENIED guard.\n\nUpgrade: `npm install -g claude-faf-mcp@5.7.2` (or one-click `.mcpb` install).\n\n### Workarounds\nIf 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.\n\n### Credits\nIdentified 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).",
"id": "GHSA-rr55-jp92-8wp2",
"modified": "2026-08-19T19:15:25Z",
"published": "2026-08-19T19:15:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Wolfe-Jam/claude-faf-mcp/security/advisories/GHSA-rr55-jp92-8wp2"
},
{
"type": "PACKAGE",
"url": "https://github.com/Wolfe-Jam/claude-faf-mcp"
},
{
"type": "WEB",
"url": "https://github.com/Wolfe-Jam/claude-faf-mcp/releases/tag/v5.7.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "claude-faf-mcp has an arbitrary local file read/write via unconfined `path` argument in FAF tools"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.