MCP file-write traversal: notebook vault containment and Ansible Lightspeed scope

What it is

Status as of 25 October 2026. Re-check both advisories for changed version ranges, deployment requirements and extension fixes. CVE-2026-61647 affects @roomi-fields/notebooklm-mcp >= 1.6.0, < 2.0.3. Its batch export functionality allowed writes outside the intended vault. Version 2.0.3 adds containment, but only when NOTEBOOKLM_VAULT_ROOT is configured; leaving it unset preserves unrestricted destination selection. Notebook server advisory.

Red Hat separately identifies CVE-2026-44192 as indirect prompt injection leading to path traversal in the Ansible Lightspeed MCP server. Its statement concerns the VS Code extension and says the vulnerable code is absent from shipped Ansible Automation Platform artifacts. It rates the issue Moderate, but provides no affected or fixed extension-version range in the reviewed advisory. Red Hat security data.

Why it matters

An agent's suggested destination is still external input. CWE-22 describes the failure to keep such paths within a restricted parent directory. Converting a string into an absolute path does not establish that it is inside the permitted root. Resolve paths before validation and enforce the boundary in the file-writing service, not only in the agent's prompt. CWE-22.

The notebook advisory describes writes of Markdown and JSON content, not automatic code execution by those files themselves. Investigations should establish what was written and whether another component later consumed it, rather than treating every unexpected document as proof that commands ran.

How to apply

• In the notebook server's installation directory, use npm ls @roomi-fields/notebooklm-mcp --depth=0; use the global listing if it was installed globally. Match the result to the actual launcher and lockfile. A listing from another project does not inventory that server. npm ls.
• Upgrade affected notebook installations to a supported release containing the 2.0.3 fix. Set NOTEBOOKLM_VAULT_ROOT=/srv/agent-vault in the server's managed environment, substituting the approved vault directory, and restart it. The configured root and the running package version are separate acceptance conditions.
• Run the writer as a dedicated account with write access limited to its output area. Review historical output locations before restoring normal service. The notebook advisory recommends this account isolation when immediate upgrading is impossible.
• For the Ansible extension, record its installed version and consult Red Hat for a confirmed remediation. Pending that confirmation, disable the affected integration where its exposure cannot be accepted; this is an operator containment measure, not a vendor-certified workaround.
• For new file tools, fix the permitted root outside model control. Validate the canonical destination against that root, constrain filenames separately, and require approval for overwrites or newly authorized destinations. Use filesystem permissions to reinforce those checks.
• Verify permitted writes in an isolated workspace and confirm that denied destinations leave no files behind. Preserve unexpected files and relevant tool-call records for investigation. Rebuild an affected environment if executable configuration was modified or unauthorized execution is established.

Pitfalls

A patched package with the containment option unset does not meet the intended boundary. Conversely, an unaffected platform package says nothing about a separately installed editor extension. Do not invent an extension fix from the platform's version number or downgrade path validation to a request that the model should be careful.