CVE-2026-61647: @roomi-fields/notebooklm-mcp has path traversal in vault.batch tool that allows arbitrary file write outside intended vault directory
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 batchtovault MCP tool beginning in version 1.7.0, because attacker-controlled vaultdir and slugprefix 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 slugprefix and supports vault containment when NOTEBOOKLMVAULTROOT 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 vaultdir values supplied by LLMs processing untrusted content.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@roomi-fields/notebooklm-mcpto a version that resolves this vulnerability.Fixed in 2.0.3 - Configuration
Configure NOTEBOOKLM_VAULT_ROOT so vault containment is enabled (containment is not enabled if NOTEBOOKLM_VAULT_ROOT is unset).
NotebookLM MCP NOTEBOOKLM_VAULT_ROOT = configured - Configuration
Validate vault_dir values supplied by LLMs/untrusted content to ensure paths remain within the intended vault directory.
NotebookLM MCP vault_dir handling vault_dir validation = strictly validate against intended vault root - Compensating control
Run NotebookLM MCP as a dedicated unprivileged account restricted to the intended vault directory.
- Compensating control
Limit the NotebookLM MCP HTTP endpoint to localhost only.
Event History
Frequently Asked Questions
Which deployments are exposed to remote exploitation?
Deployments using versions 1.6.0 through 2.0.2 are affected through the POST /batch-to-vault HTTP endpoint. The batch_to_vault MCP tool is also affected beginning with version 1.7.0; exploitation requires attacker-controlled vault_dir or slug_prefix input and a server process that can write to the target location.
Does upgrading to version 2.0.3 fully enforce the vault directory boundary by default?
No. Version 2.0.3 sanitizes slug_prefix, but vault containment is only supported when NOTEBOOKLM_VAULT_ROOT is configured. If that environment variable is unset, containment is not enabled.
What mitigations are available if an upgrade cannot be applied immediately?
Run the server under a dedicated unprivileged account whose filesystem access is restricted to the intended vault. Limit the HTTP endpoint to localhost and validate vault_dir values supplied by LLMs that process untrusted content.