High-Severity Path Traversal Hits notebooklm-mcp's Vault Tool

A single MCP tool call that writes a file. That's all it takes to turn an LLM's helper into a write-anywhere primitive — and this week that's exactly what security researchers found in notebooklm-mcp.

The advisory

The vault_batch MCP tool — and its HTTP twin, POST /batch-to-vault — took a caller-supplied vault_dir path and ran it straight through path.resolve() and fs.mkdir(). No containment check. No allowlist. Nothing standing between the input and the filesystem.

That's the part that should stop you mid-scroll. This isn't a bug that needs a malicious human at the keyboard. An MCP server's whole job is to let an LLM call tools on its behalf — so a poisoned document, a hostile web page fed into a NotebookLM session, or any other prompt-injection vector could drive vault_batch without the user ever typing the payload themselves.

There's a second, smaller hole riding along with it: the slug_prefix parameter gets concatenated directly into the output filename, giving a narrower traversal path into the same write primitive.

What's affected

• Package: @roomi-fields/notebooklm-mcp, listed on MCPpedia as io.github.roomi-fields/notebooklm-mcp
• Vector: the vault_batch tool and the POST /batch-to-vault HTTP endpoint
• Impact: arbitrary directory creation and .md/.json file writes outside the intended vault directory, bounded only by the OS permissions of the process running the server

What to do about it

Path containment for filesystem-writing tools isn't optional — it's table stakes. path.resolve() alone tells you nothing about whether the result stayed inside the directory you meant; it just normalizes ../../../etc into something that looks tidy while still pointing wherever the attacker wants.

The broader lesson travels well beyond this one server: any MCP tool that touches the filesystem based on a string an LLM can influence needs a hard boundary check, not a hope that callers behave. Until notebooklm-mcp ships one, keep it caged.