MCP `list_documents` tool exact-match lookup leaks unauthorized document metadata

Summary

The MCP list_documents tool can disclose metadata for private documents that the caller should not be able to access.

When the query argument exactly matches a document slug or urlId, the handler performs a direct document lookup and prepends the result to the response without enforcing the normal object-level read authorization check. As a result, a low-privileged user with a read-scoped MCP/OAuth/API credential can obtain metadata for private documents outside their permission set if they know a valid slug or urlId.

This appears to affect the current main branch and the latest release code path I reviewed (v1.7.1).

Details

The issue is in the MCP implementation of list_documents.

The normal search flow delegates to the access-filtered search provider, which is consistent with the tool description that it searches documents the user has access to. However, there is a separate exact-match branch for query values that look like a document slug or urlId.

In that branch, the handler directly resolves the document with:

• Document.findByPk(query, { userId: user.id })

and then prepends the returned document to the result list.

The problem is that this lookup is treated as if it were an authorization filter, but it is not. Based on the code path I reviewed, Document.findByPk(..., { userId }) preloads membership-related information but does not itself enforce the document read policy. The exact-match result is then serialized and ret…