CVE-2026-61647 in notebooklm-mcp
Summary
by MITRE • 09/22/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in NotebookLM MCP versions 1.6.0 through 2.0.2 represents a critical path traversal flaw within the POST /batch-to-vault endpoint and the associated batch_to_vault MCP tool introduced in version 1.7.0. This security defect stems from insufficient validation of user-supplied input, specifically regarding the vault_dir and slug_prefix parameters. When these values are derived from attacker-controlled sources or untrusted large language model outputs, they can contain directory traversal sequences such as dot-dot-slash characters. These sequences allow an adversary to manipulate file system paths, causing Markdown and JSON files generated by NotebookLM to be written outside of the intended vault directory structure. The severity of this issue is compounded by the fact that if the server process possesses write permissions in other directories on the host operating system, malicious actors can exploit this flaw to place arbitrary content into sensitive locations, potentially leading to remote code execution or further system compromise depending on how those files are subsequently processed.
From a technical perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal. The root cause lies in the application's failure to canonicalize and validate file paths before performing write operations. By allowing arbitrary directory components to be appended or prepended to the base vault path without rigorous sanitization, the software violates the principle of least privilege regarding file system access. This flaw is particularly dangerous because it can often be triggered indirectly through automated agents or AI-driven workflows that generate content and attempt to store it locally. The lack of strict containment mechanisms in versions prior to 2.0.3 means that any entity with network access to the HTTP endpoint or MCP tool interface could potentially abuse this functionality, especially if the service is exposed beyond localhost without additional security controls.
The operational impact of this vulnerability extends beyond simple data leakage. An attacker who successfully exploits this path traversal can overwrite existing configuration files, inject malicious scripts into web-accessible directories, or create hidden persistence mechanisms within system-critical folders. If NotebookLM MCP is integrated with other services that read from the vault directory, such as static site generators or documentation tools, the injected content could be rendered to end-users, facilitating cross-site scripting or phishing attacks. Furthermore, because the vulnerability affects both direct HTTP interactions and programmatic API calls via the MCP protocol, it presents a broad attack surface for automated exploitation scripts targeting AI-driven applications that rely on local file storage for knowledge bases or personal vaults.
Mitigation strategies focus primarily on upgrading to version 2.0.3 or later, which implements sanitization of the slug_prefix parameter and introduces support for vault containment when the NOTEBOOKLM_VAULT_ROOT environment variable is explicitly configured. However, it is crucial to note that this containment feature remains inactive if the environment variable is not set, leaving systems vulnerable even after upgrading unless proper configuration is applied. For organizations unable to immediately upgrade due to compatibility or testing constraints, several defensive measures are recommended. The server should be executed under a dedicated unprivileged account with restricted file system permissions limited strictly to the intended vault directory. Additionally, network exposure must be minimized by binding the HTTP endpoint exclusively to localhost if remote access is not required. Finally, any integration involving large language models processing untrusted content must include rigorous validation of all output parameters before they are passed to the vault writing functions, ensuring that only expected alphanumeric characters and safe path structures are accepted.