mcp-memory-keeper: Arbitrary local file read in context_import via unvalidated filePath
Impact
context_import passed the caller-supplied filePath directly to fs.readFileSync with no path confinement. A malicious MCP client — or an LLM agent that is prompt-injected into calling the tool — could point filePath at any file readable by the server process, outside any session or export directory:
- Full disclosure (JSON files): a valid-JSON target (e.g. another user's exported session, or a
*.jsoncredential / service-account file) is parsed and imported into the caller's session, then retrievable verbatim viacontext_get/context_export. - Partial disclosure (any file): for a non-JSON target (e.g.
/etc/passwd, an SSH key, a.env),JSON.parsethrows and V8 includes a snippet of the file's leading bytes in theSyntaxErrormessage, which was returned verbatim to the caller.
Both ../ traversal and absolute paths worked — there was no path confinement of any kind.
In a typical MCP deployment the server runs on the developer's machine, so the reachable set includes other users' exported memory sessions, JSON credential/config files, and (in leading-bytes form) .env files, SSH keys, and /etc/passwd. The trigger is a tool argument, so the realistic threat model is an LLM agent prompt-injected into calling context_import, or any MCP client connected to the server.
Patches
Fixed in 0.13.0 (PR #36):
- Imports are confined to a server-owned exports directory (
<DATA_DIR>/exports, overridable viaMEMORY_KEEPER_EXPORT_DIR), resolved withrealpathSync.../traversal, absolute paths outside the directory, and symlink escapes are all rejected. - File read and
JSON.parseare separate operations; read/parse failures return a generic message and never echo file bytes (theSyntaxError-message leak is gone). The database-write path is likewise generic. - An E2E security regression suite covers the reported arbitrary-read and traversal vectors, plus symlink escape, the directory-prefix boundary, and a no-existence-oracle check.
Workarounds
Upgrade to >= 0.13.0. There is no configuration-only workaround for affected versions.
Resources
- Report: GitHub issue #35
- Fix: PR #36
Credit
Reported by Zhihao Zhang (@mcfly-zzh).
Czego dotyczy
Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.
| Platforma | Paczka | Podatne wersje | Poprawka w wersji |
|---|---|---|---|
| Paczka npm | mcp-memory-keeper | < 0.13.0 | 0.13.0 |
Odnośniki
- https://github.com/mkreyman/mcp-memory-keeper/security/advisories/GHSA-f7wf-v2vw-mpcx
- https://github.com/mkreyman/mcp-memory-keeper/issues/35
- https://github.com/mkreyman/mcp-memory-keeper/pull/36
- https://github.com/mkreyman/mcp-memory-keeper/commit/84f6dfa692736a34ff36e2d2cf2188b71facf73b
- https://github.com/mkreyman/mcp-memory-keeper
- https://github.com/mkreyman/mcp-memory-keeper/releases/tag/v0.13.0
- Wektor CVSS
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N- Słabość (CWE)
CWE-209, CWE-22- Platforma
- npm
- Paczka
mcp-memory-keeper- Ujawniono
- 17.07.2026
- Aktualizacja
- 11.10.2026 10:22
Źródła i licencje
OSV / GitHub Advisory Database - GHSA-f7wf-v2vw-mpcx - CC BY 4.0
Historia podatności: mcp-memory-keeper
Wszystkie opisane podatności tej paczki (Paczka npm), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.
To jedyna znana podatność tej paczki.
Dowiedz się, które podatności dotyczą Twojej aplikacji
Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.