CVE-2026-72805: Missing Authorization in SiYuan Note Block APIs Leads to Information Disclosure

SiYuan Note is an open-source, local-first personal knowledge management system that supports fine-grained block-level editing and markdown formats. To facilitate content sharing, the application includes a 'Publish Mode' that lets users serve selected notebooks to external readers. Within this model, administrators can restrict access down to individual notebooks or documents, enforcing password protection or completely forbidding publication.\n\nThe attack surface for this system includes the API endpoints exposed during Publish Mode. While primary content-delivery APIs are designed to check read authorization, several metadata and auxiliary endpoints did not undergo identical scrutiny. Specifically, the application exposed endpoints for retrieving block structures, parent paths, and block references without validating whether those blocks belonged to restricted files.\n\nThis flaw is classified under CWE-862 (Missing Authorization) and carries a CVSS v4.0 base score of 6.9. It allows unauthenticated network attackers or low-privileged accounts to bypass document-level privacy controls. By submitting requests targeting specific block identifiers, an unauthorized actor can partially reconstruct protected document trees and extract restricted content.

The root cause of CVE-2026-72805 lies in the uneven application of authorization filters within the block-related API routers in the kernel/api/block.go module. The core content-retrieval function, getBlockInfo, implemented a validation routine known as checkBlockPublishAccess. This helper validated if the request environment operated under a read-only context and verified whether the target block ID belonged to an authorized, published resource.\n\nHowever, several parallel API endpoints handling block metadata did not execute this validation logic. The affected handlers include getBlockTreeInfos, getBlockSiblingID, getBlockRelevantIDs, getRefText, and getBlockBreadcrumb. These endpoints processed incoming JSON requests and directly invoked corresponding database service layers such as model.GetBlockTreeInfosInBox or model.BuildBlockBreadcrumbInBox using only the user-provided block ID.\n\nBecause the backend failed to assert whether the queried block identifier was part of a published, non-password-protected notebook, the database queries succeeded unconditionally. This design flaw allowed the retrieval of structure and content snippets from blocks inside encrypted SQLCipher databases, crossing planned notebook boundaries. Security boundaries became ineffective because the application assumed the client already possessed legitimate access based solely on knowing or guessing a block ID.\n\nmermaid\ngraph LR\n A["Unauthenticated Attacker"] --> B["API Endpoint: /api/block/getRefText"]\n B --> C{"Check Authorization?"}\n C -->|No| D["Query SQLCipher DB directly"]\n D --> E["Leak sensitive block content"]\n

The patch resolved the authorization omissions by updating the routing handlers in kernel/api/block.go. Prior to the fix, the getBlockTreeInfos handler queried block tree information without validating the requested block IDs. The patch introduces a helper function filterBlockIDsByPublishAccess to sanitize the requested block list prior to database query execution.\n\ngo\n// Patched getBlockTreeInfos in kernel/api/block.go\nboxID := encryptedNotebookFromArg(arg)\nids = filterBlockIDsByPublishAccess(c, ids, boxID)\nret.Data = model.GetBlockTreeInfosInBox(ids, boxID)\n\n\nFor endpoints like getBlockSiblingID, getBlockRelevantIDs, getRefText, and getBlockBreadcrumb, the developers integrated isBlockPublishAccessible. If the requested block fails this access check, the endpoint returns an empty dataset or an error code instead of querying the backend model:\n\ngo\n// Patched verification logic in kernel/api/block.go\nif !isBlockPublishAccessible(c, id, boxID) {\n ret.Data = map[string]string{\n "parent": "",\n "next": "",\n "previous": "",\n }\n return\n}\n\n\nAdditionally, database querying logic in kernel/model/publish_access.go was refactored. The function CheckBlockIdAccessableByPublishAccess now delegates execution to CheckBlockIdAccessableByPublishAccessInBox. This forces lookups to remain bounded within the specific notebook (boxID) context, preventing attackers from bypassing access restrictions by targeting blocks stored in unlinked or encrypted notebooks.

An attack targeting CVE-2026-72805 requires the target SiYuan Note instance to run in Publish Mode. The attacker must obtain or predict a valid block ID belonging to a forbidden or password-protected document. Block identifiers in SiYuan are unique keys that are sometimes exposed in transaction logs, public references, or predictable sequential structures.\n\nOnce a block ID is identified, the attacker crafts direct HTTP POST requests to the vulnerable endpoints. For example, querying /api/block/getRefText with a restricted block ID bypasses access control. The backend retrieves the database representation of the block and responds with the raw text contents, ignoring the fact that the notebook itself is publish-forbidden.\n\njson\nPOST /api/block/getRefText HTTP/1.1\nHost: target-instance.local\nContent-Type: application/json\n\n{\n "id": "20260724000002-docid01"\n}\n\n\nBy executing similar queries against the sibling and breadcrumb endpoints, the attacker can map the structural layout of the private document tree. This step-by-step extraction enables an unauthorized party to reconstruct complete document paths, titles of parent folders, and content flows without providing any authentication credentials.

The security impact of this vulnerability is categorized as moderate confidentiality loss, corresponding to a CVSS v4.0 base score of 6.9. Because the vulnerability is restricted to information disclosure, there is no threat to system integrity or availability. However, for users relying on password protection or publishing restrictions to protect intellectual property or sensitive logs, this vulnerability constitutes a direct bypass of those security controls.\n\nThe scope is local to the published notebook instance, but the impact can extend to secondary boundaries. This is because document hierarchies or breadcrumbs may leak information about user-system file paths or other organizational structures. The exploitation complexity is low, and no user interaction is required, raising the likelihood of successful automated scraping if block IDs are discovered.\n\nCurrently, there are no records indicating active exploitation in the wild, nor have weaponized exploit payloads been cataloged. The EPSS score remains low, suggesting that mass targeting of this vulnerability is unlikely. Nevertheless, because private knowledge bases often contain high-value data such as internal hostnames, passwords, and sensitive narratives, prompt mitigation is necessary.

The primary remediation path is upgrading the SiYuan Note application to version v3.7.4 or later. This release introduces complete authorization validation on all exposed metadata and relational block endpoints. The security mechanisms fully integrate the isBlockPublishAccessible validation, preventing queries from escaping the authorized scope.\n\nFor instances where immediate updates are impractical, administrators should disable Publish Mode entirely. If the notebook is strictly meant for private use, keeping Publish Mode inactive removes the vulnerable attack surface from network exposure. This is the most effective operational workaround to guarantee confidentiality.\n\nAdditionally, network-level access controls should be deployed. Administrators can restrict traffic to the SiYuan Note interface via a reverse proxy (e.g., Nginx, Caddy) combined with IP address filtering or HTTP basic authentication. If Publish Mode is required for a subset of users, Web Application Firewall (WAF) policies should be configured to drop unauthenticated external traffic directed to /api/block/getBlockBreadcrumb, /api/block/getRefText, /api/block/getBlockTreeInfos, /api/block/getBlockSiblingID, and /api/block/getBlockRelevantIDs.