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
*.json credential / service-account file) is parsed and imported into the caller's session, then retrievable verbatim via context_get / context_export.
- Partial disclosure (any file): for a non-JSON target (e.g.
/etc/passwd, an SSH key, a .env), JSON.parse throws and V8 includes a snippet of the file's leading bytes in the SyntaxError message, 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 via MEMORY_KEEPER_EXPORT_DIR), resolved with realpathSync. ../ traversal, absolute paths outside the directory, and symlink escapes are all rejected.
- File read and
JSON.parse are separate operations; read/parse failures return a generic message and never echo file bytes (the SyntaxError-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.
References
- Report: GitHub issue #35
- Fix: PR #36
Credit
Reported by Zhihao Zhang (@mcfly-zzh).
Impact
context_importpassed the caller-suppliedfilePathdirectly tofs.readFileSyncwith no path confinement. A malicious MCP client — or an LLM agent that is prompt-injected into calling the tool — could pointfilePathat any file readable by the server process, outside any session or export directory:*.jsoncredential / service-account file) is parsed and imported into the caller's session, then retrievable verbatim viacontext_get/context_export./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)
.envfiles, SSH keys, and/etc/passwd. The trigger is a tool argument, so the realistic threat model is an LLM agent prompt-injected into callingcontext_import, or any MCP client connected to the server.Patches
Fixed in 0.13.0 (PR #36):
<DATA_DIR>/exports, overridable viaMEMORY_KEEPER_EXPORT_DIR), resolved withrealpathSync.../traversal, absolute paths outside the directory, and symlink escapes are all rejected.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.Workarounds
Upgrade to
>= 0.13.0. There is no configuration-only workaround for affected versions.References
Credit
Reported by Zhihao Zhang (@mcfly-zzh).