NotebookLM MCP 2.0.3 Restricts Vault File Writes
Tech GuruQuick Answer
NotebookLM MCP 2.0.3 sanitizes vault filenames, but directory containment requires NOTEBOOKLM_VAULT_ROOT. Without that setting, caller-controlled paths can still place Markdown and JSON files outside the intended vault wherever the server account can write. Upgrade affected 1.6.0-2.0.2 installations and configure the root; upgrading alone does not enable containment.
Confirm Scope And Apply The Supported Fix
What to do now: Record the server account's write permissions and effective vault root. Install 2.0.3, set NOTEBOOKLM_VAULT_ROOT in the server's own environment, and verify the running process received it.
Last verified: 2026-09-22 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | @roomi-fields/notebooklm-mcp 1.6.0 through 2.0.2 vault batch workflows |
|---|---|
| Advisory | GHSA-jjhp-8crj-mppq |
| CVE | CVE-2026-61647 |
| Project advisory publication | 2026-06-23 08:35:08 UTC |
| Recorded source timestamp (historical snapshot) | 2026-09-22 14:43:27 UTC |
| Affected versions | @roomi-fields/notebooklm-mcp versions 1.6.0 through 2.0.2 using vault_batch or POST /batch-to-vault. |
| Fixed version | @roomi-fields/notebooklm-mcp 2.0.3 with NOTEBOOKLM_VAULT_ROOT configured to the intended vault root |
| CVSS base score | 7.1 (CVSS v4.0, GitHub CNA record) |
| CVSS severity | High in the CNA's CVSS v4.0 record; the project GHSA labels severity Moderate. |
| Exploitation status | Not stated by the authority; no exploitation claim is inferred. |
What Changed
The HTTP batch endpoint is affected from 1.6.0; the corresponding MCP tool was introduced in 1.7.0. Version 2.0.3 always sanitizes slug_prefix, while realpath-based directory containment is opt-in. The resulting files are not executable by themselves; downstream impact depends on where another process consumes them.
What To Validate Now
- Inventory. Locate @roomi-fields/notebooklm-mcp 1.6.0 through 2.0.2 vault batch workflows deployments, versions, enabled features, exposure paths, owners, and dependent services.
- Establish applicability. Compare each deployment with the authority's affected-version statement: @roomi-fields/notebooklm-mcp versions 1.6.0 through 2.0.2 using vault_batch or POST /batch-to-vault. Do not infer applicability from product family or severity alone.
- Remediate. Apply @roomi-fields/notebooklm-mcp 2.0.3 with NOTEBOOKLM_VAULT_ROOT configured to the intended vault root through the supported vendor or project channel, following the current advisory and change-control requirements.
- Validate. In an isolated test vault, confirm normal exports succeed and out-of-root destinations are rejected with the configured root. Record the active configuration as well as the version; do not test writes against sensitive production paths.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
Until upgrade is possible, the project advises a dedicated unprivileged account restricted to the vault, a localhost-only HTTP endpoint, and validation of paths supplied by an LLM processing untrusted content. These controls do not replace the opt-in root setting after upgrade.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
