GHSA-rr55-jp92-8wp2 json
claude-faf-mcp has an arbitrary local file read/write via unconfined `path` argument in FAF tools
published 2mo ago modified 2mo ago
- cvss
- 7.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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 `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).
Patch / fix
Is GHSA-rr55-jp92-8wp2 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | claude-faf-mcp | <5.7.2 |
5.7.2 |
Classification
References
Sources
- GitHub Advisory GHSA-rr55-jp92-8wp2
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.