@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.