Summary
@roomi-fields/notebooklm-mcp has a path traversal in vault.batch tool that allows arbitrary file write outside intended vault directory
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.
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-vaultendpoint beyond localhost. - If using an LLM that ingests untrusted content, validate any
vault_dirarguments 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.
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.
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in v2.0.3:
- Opt-in containment via
NOTEBOOKLM_VAULT_ROOTenv var. When set,vault_diris resolved relative to that root andrealpath-based containment is enforced. Absolute paths or..segments outside the root are rejected with a clear error. slug_prefixis always sanitized. Path separators (/,\),..sequences and NUL bytes are stripped, length capped at 64 characters. This applies regardless of whetherNOTEBOOKLM_VAULT_ROOTis set.- 15 unit tests in
src/__tests__/vault-writer.test.tscover the escape vectors (absolute paths, sibling-prefix attacks,..traversal, NUL/separator stripping).
Frequently Asked Questions
- What is CVE-2026-61647? CVE-2026-61647 is a high-severity path traversal vulnerability in @roomi-fields/notebooklm-mcp (npm), affecting versions >= 1.6.0, < 2.0.3. It is fixed in 2.0.3. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- Which versions of @roomi-fields/notebooklm-mcp are affected by CVE-2026-61647? @roomi-fields/notebooklm-mcp (npm) versions >= 1.6.0, < 2.0.3 is affected.
- Is there a fix for CVE-2026-61647? Yes. CVE-2026-61647 is fixed in 2.0.3. Upgrade to this version or later.
- Is CVE-2026-61647 exploitable, and should I be worried? Whether CVE-2026-61647 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-61647 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-61647? Upgrade
@roomi-fields/notebooklm-mcpto 2.0.3 or later.