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

• npm @roomi-fields/notebooklm-mcp: >= 1.6.0, < 2.0.3 → fixed in 2.0.3

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.