SiYuan: Missing publish-access check on getBlockBreadcrumb, getRefText, and getBlockTreeInfos discloses content and metadata of protected/forbidden documents

CVE: This vulnerability corresponds to CVE-2026-72805.

Summary

Three block endpoints return document content snippets and metadata without any publish-access check, while their sibling getBlockInfo which returns comparable data does enforce one. All three are CheckAuth-only, so they are reachable by the publish RoleReader token and by the anonymous account when Publish.Auth.Enable is false. An anonymous reader supplying a block ID receives content and metadata belonging to publish-forbidden and password-protected documents.

Details

getBlockInfo (kernel/api/block.go) gates on the publish boundary:

if !checkBlockPublishAccess(c, id, ret) {
    return
}

The following siblings in the same file perform no equivalent check:

getBlockBreadcrumb returns the full ancestor chain including each ancestor block's content snippet, and getRefText returns block anchor text both are document content, not just metadata. getBlockTreeInfos returns root/title/path for any caller-supplied ID set via model.GetBlockTreeInfosInBox(...) with no gate.

getBlockBreadcrumb and getRefText additionally accept a client-supplied notebook argument that routes to the *InBox variants, so the same unguarded path applies to encrypted-notebook reads while the notebook is unlocked.

The correct primitive already exists in the codebase and is used by getBlockInfo; these three handlers simply do not call it.

Proof of Concept

Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false, otherwise any publish reader account. A document D is marked publish-forbidden (or password-protected) and contains a block BLOCK_ID under a heading with distinctive content.

Control: the gated sibling correctly refuses:

POST http://127.0.0.1:6808/api/block/getBlockInfo
{"id":"BLOCK_ID"}

Blocked by checkBlockPublishAccess.

Disclosure: the ungated siblings return the data anyway:

POST http://127.0.0.1:6808/api/block/getBlockBreadcrumb
{"id":"BLOCK_ID"}
→ ancestor chain including the forbidden document's title and ancestor block content snippets

POST http://127.0.0.1:6808/api/block/getRefText
{"id":"BLOCK_ID"}
→ the block's reference/anchor text (content of the forbidden document)

POST http://127.0.0.1:6808/api/block/getBlockTreeInfos
{"ids":["BLOCK_ID"]}
→ root ID, title, and path for the forbidden document

Verified by code inspection at origin/master (eef10568): getBlockInfo contains the checkBlockPublishAccess call; getBlockBreadcrumb, getRefText, and getBlockTreeInfos contain no publish-access, publish-ignore, or readonly-role check in their bodies.

Impact

An anonymous reader (publish mode with auth disabled) or any publish RoleReader can read, for documents explicitly excluded from publishing or protected by a publish password:

• the document title and full ancestor chain, including ancestor block content snippets (getBlockBreadcrumb);
• block reference/anchor text, i.e. document content (getRefText);
• root ID, title, and path metadata for arbitrary block IDs (getBlockTreeInfos).

Because getBlockBreadcrumb and getRefText accept a notebook argument routing to the *InBox variants, the same disclosure applies to encrypted notebooks while unlocked. Confidentiality-only; the precondition is a block ID, obtainable from other reader-reachable endpoints.

Suggested fix

Call checkBlockPublishAccess (as getBlockInfo does) in getBlockBreadcrumb, getRefText, and getBlockTreeInfos before returning data for getBlockTreeInfos, apply it per ID and drop unauthorized entries. Confirm the *InBox variants (GetBlockRefTextInBox, BuildBlockBreadcrumbInBox) enforce the same boundary so the notebook-argument path is covered.