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.
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.
Fixed in v2.0.3:
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.src/__tests__/vault-writer.test.ts cover the escape vectors (absolute paths, sibling-prefix attacks, .. traversal, NUL/separator stripping)./batch-to-vault endpoint beyond localhost.vault_dir arguments before forwarding them to the MCP.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.
Reported by @mcfly-zzh — thanks for the careful diagnosis and follow-up verification.
{
"cwe_ids": [
"CWE-22",
"CWE-73"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T14:43:26Z",
"nvd_published_at": "2026-09-21T21:17:07Z",
"severity": "HIGH"
}