GHSA-67x2-mq63-v9vm: Medium severity go/github.com/siyuan-note/siyuan/kernel vulnerability
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: go if !checkBlockPublishAccess(c, id, ret) { return }
The following siblings in the same file perform no equivalent check:
| Endpoint | Returns | Publish check | |---|---|---| | getBlockInfo | root/title/path metadata | checkBlockPublishAccess: present | | getBlockBreadcrumb | BlockPath.Name : root document title plus every ancestor block's content snippet | none | | getRefText | the block's reference/anchor text (document content) | none | | getBlockTreeInfos | root/title/path metadata for arbitrary block IDs | none |
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 BLOCKID under a heading with distinctive content.
Control: the gated sibling correctly refuses: POST http://127.0.0.1:6808/api/block/getBlockInfo {"id":"BLOCKID"} Blocked by checkBlockPublishAccess.
Disclosure: the ungated siblings return the data anyway: POST http://127.0.0.1:6808/api/block/getBlockBreadcrumb {"id":"BLOCKID"} → ancestor chain including the forbidden document's title and ancestor block content snippets
POST http://127.0.0.1:6808/api/block/getRefText {"id":"BLOCKID"} → the block's reference/anchor text (content of the forbidden document)
POST http://127.0.0.1:6808/api/block/getBlockTreeInfos {"ids":["BLOCKID"]} → 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/siyuan-note/siyuan/kernelto a version that resolves this vulnerability.Fixed in 0.0.0-20260723163028-931ba693375e - Configuration
Ensure publish authentication is enabled so anonymous/publish mode cannot use publish `RoleReader` token paths to call block endpoints that lack publish-access checks.
Publish.Auth.Enable Publish.Auth.Enable = true - Configuration
In the block API handlers `getBlockBreadcrumb`, `getRefText`, and `getBlockTreeInfos`, add the existing `checkBlockPublishAccess(c, id, ret)` call before returning any data for each requested block ID; drop unauthorized entries per ID (mirroring the gating behavior already present in `getBlockInfo`).
API endpoints Block endpoint authorization = enforce checkBlockPublishAccess - Configuration
Confirm/implement that the notebook-argument routes to the `*InBox` variants (`GetBlockRefTextInBox`, `BuildBlockBreadcrumbInBox`) enforce the same publish-access boundary, since the notebook argument currently routes to variants that follow the same unguarded disclosure behavior.
Inbox notebook routing *InBox variants authorization = enforce same publish boundary
Event History
Frequently Asked Questions
Who can access the affected endpoints?
The endpoints are reachable by a publish RoleReader token. They are also reachable by an anonymous account when Publish.Auth.Enable is false.
What does an attacker need to retrieve protected content?
An attacker needs to supply a block ID to the affected endpoint. The missing publish-access checks can then expose content snippets or metadata from publish-forbidden and password-protected documents.
Which endpoints lack the publish-access check?
getBlockBreadcrumb, getRefText, and getBlockTreeInfos lack the equivalent publish-boundary check present in getBlockInfo. The exposed data includes breadcrumb content snippets, reference or anchor text, and root, title, or path metadata.