### Summary A low-privilege MCP token holder with knowledge of an attachment path could read any file in shared storage, including attachments belonging to other bases and workspaces, because the MCP `readAttachment` tool did not verify the file's ownership. ### Details The MCP `readAttachment` tool accepts caller-supplied `path`/`url` values and streams the file via the storage adapter. The handler now looks up the path in `nc_file_references` and requires a non-deleted row whose `base_id` matches the caller's MCP context before streaming; otherwise it returns `Attachment is not accessible from this MCP context`. The lookup tolerates both `download/uploads/...` and `uploads/...` styles. ### Impact Arbitrary read against shared storage scoped to attachments the caller's MCP context should not see. Exploitation requires an MCP token and a known attachment path. ### Credit This issue was reported by [@helwor-01](https://github.com/helwor-01).
Get alerted for CVEs like this
Register your stack and get notified within minutes when a matching CVE drops.
Start monitoring free