CVE-2026-61647: @roomi-fields/notebooklm-mcp has a path traversal in vault.batch tool that allows arbitrary file write outside intended vault directory

vault_dir goes straight into path.resolve() and fs.mkdir(). The server then writes the answer files as markdown with JSON sidecars into that directory. A second, smaller flaw: slug_prefix is concatenated into the filename without sanitizing, so a prefix with / or .. can escape the resolved vault directory.

The attacker needs to reach the MCP tool or the HTTP endpoint. The CVSS vector requires low privileges. The usual route is an LLM driving the MCP server that has read untrusted content, which injects a vault_dir argument. The written files are inert content and give no code execution by themselves. The risk is planting files in sensitive places such as autostart folders or shell startup files for a later step, and overwriting files in locations the process can write. Integrity is the affected property.

The flaw has existed since 1.6.0, when /batch-to-vault was introduced, and since 1.7.0 for the batch_to_vault MCP tool, through 2.0.2.

@roomi-fields/notebooklm-mcp >= 1.6.0, < 2.0.3. The HTTP /batch-to-vault endpoint is exposed since 1.6.0 and the MCP tool since 1.7.0. Servers run by a user with broad write access, or driven by an LLM that reads untrusted content, are the most exposed.

npm ls -g @roomi-fields/notebooklm-mcp

Upgrade to @roomi-fields/notebooklm-mcp 2.0.3:

npm install -g @roomi-fields/[email protected]

Important: 2.0.3 keeps the old unrestricted behavior when NOTEBOOKLM_VAULT_ROOT is unset, so existing local setups keep working. Set NOTEBOOKLM_VAULT_ROOT to the directory that should bound all vault writes. With it set, vault_dir is resolved under that root with realpath containment, and absolute paths or .. outside it are rejected. slug_prefix is always sanitized: separators, .. and NUL are stripped and the length is capped at 64 characters.

If you cannot upgrade, run the server as an unprivileged user that can write only to the vault, do not expose the HTTP endpoint beyond localhost, and validate vault_dir before passing it on.

Search for unexpected .md and .json files outside the vault, especially in autostart folders, home-directory dotfile locations and other users' directories, with names that look like notebook answers. Review MCP tool-call logs and HTTP logs for vault_batch or /batch-to-vault requests with an absolute vault_dir, .. segments, or a slug_prefix containing slashes. Beam records MCP tool calls and file access, so its rules can flag vault_dir arguments pointing outside your project.

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.