@roomi-fields/notebooklm-mcp has a path traversal in vault.batch tool that allows arbitrary file write outside intended vault directory

Summary

The vault_batch MCP tool (and the equivalent POST /batch-to-vault HTTP endpoint) accepted a caller-supplied vault_dir 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 slug_prefix 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.

Impact

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 batch_to_vault MCP tool) through v2.0.2.

Patch

Fixed in v2.0.3:

• Opt-in containment via NOTEBOOKLM_VAULT_ROOT env var. When set, vault_dir 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.
• slug_prefix is always sanitized. Path separators (/, \), .. sequences and NUL bytes are stripped, length capped at 64 characters. This applies regardless of whether NOTEBOOKLM_VAULT_ROOT 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 vault_dir arguments before forwarding them to the MCP.

Configuration requirement after upgrade (important)

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

Credit

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