CVE-2026-61647

NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the POST /batch-to-vault endpoint, also exposed through the batch_to_vault MCP tool beginning in version 1.7.0, because attacker-controlled vault_dir and slug_prefix values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes slug_prefix and supports vault containment when NOTEBOOKLM_VAULT_ROOT is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate vault_dir values supplied by LLMs processing untrusted content.

NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the POST /batch-to-vault endpoint, also exposed through the batch_to_vault MCP tool beginning in version 1.7.0, because attacker-controlled vault_dir and slug_prefix values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes slug_prefix and supports vault containment when NOTEBOOKLM_VAULT_ROOT is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate vault_dir values supplied by LLMs processing untrusted content.

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.

NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the POST /batch-to-vault endpoint, also exposed through the batch_to_vault MCP tool beginning in version 1.7.0, because attacker-controlled vault_dir and slug_prefix values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes slug_prefix and supports vault containment when NOTEBOOKLM_VAULT_ROOT is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate vault_dir values supplied by LLMs processing untrusted content.

NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the POST /batch-to-vault endpoint, also exposed through the batch_to_vault MCP tool beginning in version 1.7.0, because attacker-controlled vault_dir and slug_prefix values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes slug_prefix and supports vault containment when NOTEBOOKLM_VAULT_ROOT is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate vault_dir values supplied by LLMs processing untrusted content.

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.