NotebookLM MCP server patched over arbitrary file write flaw

A path traversal vulnerability in the npm package @roomi-fields/notebooklm-mcp allowed arbitrary file writes outside the intended vault directory, according to a GitHub security advisory published on 22 September 2026. The flaw, tracked as CVE-2026-61647, affects versions 1.6.0 through 2.0.2 and is fixed in version 2.0.3.

The advisory says the vault_batch MCP tool, and the equivalent POST /batch-to-vault HTTP endpoint, accepted a caller-supplied vault_dir path. That value was passed directly to path.resolve() and fs.mkdir() with no containment check. As a result, a caller could create directories and write Markdown and JSON answer files anywhere the server process had permission to write.

A second, smaller vector involved the slug_prefix parameter. According to the advisory, the prefix was concatenated into the filename without sanitisation, so a value containing a forward slash or .. could escape the resolved vault directory through the filename component.

The maintainers describe the written files as inert content that does not by itself lead to code execution. The concern is what those files could be used for. In a multi-user context, or where the MCP server is driven by a large language model that has read untrusted content, the advisory says an attacker could plant files in sensitive locations such as autostart folders or shell startup files for downstream exploitation. MCP, the Model Context Protocol, is the interface that lets an AI assistant call external tools like this one.

That framing matters because prompt injection is the plausible delivery route. If a model reads attacker-controlled text and then calls the tool, the model itself supplies the malicious vault_dir argument. No direct network access to the server is needed.

The advisory dates the problem to v1.6.0, when the HTTP /batch-to-vault endpoint was introduced, and notes the same logic was exposed as the batch_to_vault MCP tool in v1.7.0. Everything up to and including v2.0.2 is affected.

The fix in v2.0.3 has two parts. Containment is now available through a NOTEBOOKLM_VAULT_ROOT environment variable. When it is set, vault_dir is resolved relative to that root and containment is enforced using realpath, with absolute paths or .. segments outside the root rejected with an error. Separately, slug_prefix is always sanitised: path separators, .. sequences and NUL bytes are stripped, and the length is capped at 64 characters. That sanitisation applies whether or not the environment variable is set. The maintainers added 15 unit tests covering absolute paths, sibling-prefix attacks, .. traversal and separator stripping.

Users should note an important caveat. The advisory states that v2.0.3 preserves the legacy unrestricted behaviour when NOTEBOOKLM_VAULT_ROOT is unset, in order to keep existing single-user local setups working. Upgrading alone does not turn containment on. Operators must set the variable to a directory that should bound all vault writes.

For those who cannot upgrade, the advisory suggests running the MCP server under a dedicated unprivileged user with write access only to the intended vault directory, keeping the HTTP /batch-to-vault endpoint restricted to localhost, and validating any vault_dir arguments before forwarding them to the MCP where the driving model ingests untrusted content.

The issue was reported by a community researcher credited in the advisory as @mcfly-zzh.