Is @roomi-fields/notebooklm-mcp safe?

GHSA-jjhp-8crj-mppq

The vaultbatch MCP tool (and the equivalent POST /batch-to-vault HTTP endpoint) accepted a caller-supplied vaultdir path that was passed directly to path.resolve() + fs.mkdir() with no containment check. A caller — or a prompt-injected LLM driving the MCP — could therefore create directories and write .md / .json answer files anywhere the server process can write.

The slugprefix parameter had a parallel, smaller traversal vector: it was concatenated into the filename without sanitization, so a prefix containing / or .. could escape the resolved vault directory through the filename component.

File write (markdown + JSON sidecars) to any location writable by the server process. The written files are inert content (no code execution by themselves), but in a multi-user context — or when the MCP server is driven by an LLM that has read untrusted content (prompt injection) — this allows an attacker to plant files in sensitive locations (autostart folders, shell startup files, etc.) for downstream exploitation.

The vulnerability exists from v1.6.0 (when the HTTP /batch-to-vault endpoint was introduced) and v1.7.0 (when the same logic was exposed as the batchtovault MCP tool) through v2.0.2.

Fixed in v2.0.3:

• Opt-in containment via NOTEBOOKLMVAULTROOT env var. When set, vaultdir is resolved relative to that root and realpath-based containment is enforced. Absolute paths or .. segments outside the root are rejected with a clear error. • slugprefix is always sanitized. Path separators (/, \), .. sequences and NUL bytes are stripped, length capped at 64 characters. This applies regardless of whether NOTEBOOKLMVAULTROOT is set. • 15 unit tests in src/tests/vault-writer.test.ts cover the escape vectors (absolute paths, sibling-prefix attacks, .. traversal, NUL/separator stripping).

Workarounds for users who cannot upgrade

• Run the MCP server under a dedicated unprivileged user with write access only to the intended vault directory. • Do not expose the HTTP /batch-to-vault endpoint beyond localhost. • If using an LLM that ingests untrusted content, validate any vaultdir arguments before forwarding them to the MCP.

Configuration requirement after upgrade (important)

v2.0.3 preserves the legacy unrestricted behaviour when NOTEBOOKLMVAULTROOT is unset, to keep existing single-user local setups working. To enable containment, set NOTEBOOKLMVAULTROOT in the server environment to a directory that should bound all vault writes.

Reported by @mcfly-zzh — thanks for the careful diagnosis and follow-up verification.