GHSA-hqh4-75hx-xq46: 
Python vulnerability analysis and mitigation

Impact

memtomem-stm runs executables by bare name while its working directory is the user's project: the LTM server (memtomem-server by default) and stdio upstream servers, started by the proxy, by hooks and by the hook-started daemon, and checked by mms doctor/health probes; claude and codex from mms init, mms add --from-clients, mms import, mms host status|scan|sync, mms prune, mms doctor, register/unregister and eject; and pgrep from the proxy's and daemon's child cleanup. A bare name is resolved through PATH at spawn time, and a relative PATH entry (., an empty segment, bin) is resolved against that working directory. Where the code checks shutil.which(...) first, the check resolves the same way, and the one site that spawns the which result (codex mcp list) receives the same relative path. So in a project an attacker controls, an executable with one of those names placed where a relative PATH entry points runs with the user's privileges when the proxy is started there by an MCP client (LTM server, upstream servers, pgrep) or when one of the commands above runs there.

• POSIX: requires a relative entry in the user's PATH. Measured on macOS (Python 3, parent cwd = project): with PATH=.:/abs, :/abs or bin:/abs, shutil.which("claude") returned the project's file.
• Windows: CreateProcess and shutil.which (which the MCP SDK uses for stdio commands) search the current directory for a bare name unless NoDefaultCurrentDirectoryInExePath exists in the environment, so the default configuration is affected. Measured on windows-latest with Python 3.12: without the variable, both shutil.which and a bare-name subprocess spawn picked an executable placed in the current directory over the one on PATH; with the fix, both picked the one on PATH.

Affected call sites (0.7.2)

• stdio servers: surfacing/mcp_client.py (LTM), proxy/manager.py (upstreams), proxy/toolgraph_provider.py, cli/proxy.py doctor/health probes.
• claude: src/memtomem_stm/cli/proxy.py registration helpers (mcp get/add/remove), _plugin_bypass_servers (plugin list --json), the scope removal helper, eject restore.
• codex: proxy.py registration helpers (mcp get/add/remove, get --json, planned commands) and cli/host_bypass.py codex_extra_servers (mcp list --json).
• pgrep: src/memtomem_stm/utils/child_reaper.py (POSIX only), reached from the proxy and from daemon cleanup.
• shutil.which presence checks used to choose a path: proxy.py init mode selection, plugin bypass, stdio command check, doctor registration checks. Not affected: the daemon re-spawn uses sys.executable (absolute). Commands configured with a path (./x, /abs/x) are an explicit choice and are run as given.

Patches

At startup STM removes PATH entries that are not fully qualified (relative, empty, drive-relative or root-relative) and, on Windows, sets NoDefaultCurrentDirectoryInExePath. Every lookup STM makes keeps its own rules but no longer consults the current directory, and processes STM starts inherit the hardened PATH. Lookups those processes make later are their own (on Windows a stdio server does not inherit the variable). An upstream server's own configured env.PATH is used as given. A tool reachable only that way is no longer found by STM. An empty or absent PATH, or one with no fully qualified entry left, is replaced by the platform default without its current-directory entry (/bin:/usr/bin; C:\bin on Windows). Not changed: hook commands STM installs (memtomem-stm … or uv run … memtomem-stm …) and MCP registrations written by older versions or by hand are looked up by the client itself, in its own process. Current registrations use an absolute interpreter path.

Workarounds

Remove relative entries (., empty segments, relative or root-relative directories) from PATH. On Windows, define NoDefaultCurrentDirectoryInExePath in the environment the MCP client and your shell start with.