CVE-2026-61647: NotebookLM MCP Path Traversal Vulnerability

CVE-2026-61647 Overview

CVE-2026-61647 is a path traversal vulnerability [CWE-22] in NotebookLM MCP, an MCP server and HTTP service that interfaces with Google NotebookLM and exports generated content to local vault directories. Affected versions 1.6.0 through 2.0.2 expose the POST /batch-to-vault endpoint and, starting in version 1.7.0, the batch_to_vault MCP tool. Attacker-controlled vault_dir and slug_prefix parameters allow Markdown and JSON files to be written outside the intended vault directory. The write occurs anywhere the server process has permissions, enabling integrity impact on the host filesystem.

Critical Impact

An authenticated attacker can write arbitrary Markdown and JSON files to any location writable by the NotebookLM MCP server process, potentially overwriting configuration, scripts, or startup files.

Affected Products

• NotebookLM MCP versions 1.6.0 through 2.0.2 (POST /batch-to-vault endpoint)
• NotebookLM MCP versions 1.7.0 through 2.0.2 (batch_to_vault MCP tool)
• Deployments without NOTEBOOKLM_VAULT_ROOT configured after upgrade

Discovery Timeline

• 2026-09-21 - CVE-2026-61647 published to NVD
• 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-61647

Vulnerability Analysis

The vulnerability resides in the batch-to-vault write path, which accepts vault_dir and slug_prefix inputs from the HTTP request or the MCP tool invocation. Neither input is sanitized against directory traversal sequences or absolute path components before being joined into the final output path. As a result, sequences such as ../ in slug_prefix or an absolute path in vault_dir cause file writes to escape the intended vault directory.

The service produces Markdown and JSON output files. An attacker can direct those writes to any filesystem location the server process can access. In default deployments, that process often runs as the invoking user, exposing shell startup files, cron entries, SSH authorized_keys, or MCP client configuration to overwrite.

The attack requires low privileges because the endpoint is intended for local automation and does not enforce path containment. When large language models process untrusted content and invoke the batch_to_vault tool, an indirect prompt injection can trigger the traversal without direct attacker access to the endpoint.

Root Cause

The root cause is missing validation of user-supplied path components before filesystem writes. Versions prior to 2.0.3 do not canonicalize the resolved path or verify that it remains inside a designated vault root. The NOTEBOOKLM_VAULT_ROOT containment check was not present, so slug_prefix traversal sequences and unconstrained vault_dir values reached fs.writeFile-equivalent calls unchecked.

Attack Vector

Exploitation occurs over the network against the HTTP endpoint or through the MCP tool interface. An attacker submits a crafted POST /batch-to-vault request supplying a vault_dir pointing to a sensitive directory or a slug_prefix containing ../ sequences. Alternatively, an LLM processing attacker-controlled documents can be induced to invoke batch_to_vault with malicious parameters, chaining prompt injection into filesystem write primitives.

Refer to the GitHub Security Advisory GHSA-jjhp-8crj-mppq for maintainer analysis and version details.

Detection Methods for CVE-2026-61647

Indicators of Compromise

• Files with .md or .json extensions appearing in system directories outside the configured vault, particularly under user home directories, /etc, or startup paths.
• HTTP access logs showing POST /batch-to-vault requests containing ../, absolute paths, or unexpected characters in vault_dir or slug_prefix fields.
• Unexpected modifications to shell profile files (.bashrc, .zshrc), SSH authorized_keys, or MCP client configuration authored by the NotebookLM MCP service account.

Detection Strategies

• Inspect request bodies to /batch-to-vault for path traversal tokens and reject or alert on any occurrence of .., leading /, or drive-letter prefixes in slug_prefix.
• Enable filesystem audit logging (auditd, Windows Object Access) on the parent directory tree to capture writes originating from the NotebookLM MCP process outside the vault root.
• Correlate MCP tool invocations with subsequent file creation events to identify anomalous write destinations tied to batch_to_vault calls.

Monitoring Recommendations

• Baseline the expected write locations of the NotebookLM MCP process and alert on writes to any path outside NOTEBOOKLM_VAULT_ROOT.
• Monitor the HTTP endpoint for external network exposure; alert if the listener binds to anything other than 127.0.0.1.
• Review LLM prompt and tool-invocation traces for batch_to_vault calls originating from processing of untrusted third-party content.

How to Mitigate CVE-2026-61647

Immediate Actions Required

• Upgrade NotebookLM MCP to version 2.0.3 or later, which sanitizes slug_prefix and supports vault containment.
• Set the NOTEBOOKLM_VAULT_ROOT environment variable after upgrading; containment is not enforced when this variable is unset.
• Restrict the HTTP listener to localhost and place the endpoint behind local authentication if remote access is required.

Patch Information

Version 2.0.3 introduces sanitization of the slug_prefix parameter and enforces vault containment when NOTEBOOKLM_VAULT_ROOT is configured. The upgrade alone does not close the issue unless the environment variable is also set. See the GitHub Security Advisory for full remediation details.

Workarounds

• Run the NotebookLM MCP server under a dedicated unprivileged account whose filesystem access is limited to the intended vault directory.
• Bind the HTTP endpoint exclusively to 127.0.0.1 and block external network reachability at the host firewall.
• Validate vault_dir values before passing them to the MCP tool, particularly when LLMs process untrusted or externally sourced content.
• Apply mandatory access control (AppArmor, SELinux) profiles that restrict write access of the server process to the vault directory only.

# Configuration example: enforce vault containment on upgrade to 2.0.3+
export NOTEBOOKLM_VAULT_ROOT="/var/lib/notebooklm/vault"

# Bind the HTTP service to localhost only (example systemd override)
# /etc/systemd/system/notebooklm-mcp.service.d/override.conf
# [Service]
# Environment="HOST=127.0.0.1"
# Environment="NOTEBOOKLM_VAULT_ROOT=/var/lib/notebooklm/vault"
# User=notebooklm
# ReadWritePaths=/var/lib/notebooklm/vault