CVE-2026-68587: Broken Access Control in SiYuan Note Transaction Endpoints

SiYuan Note is a privacy-first personal knowledge management workspace that allows users to manage and publish documents. When configured in publish mode, a designated subset of documents is made accessible to anonymous readers via the web. This deployment model establishes a distinct security boundary between public-facing documents and the unpublished, private contents of the workspace.

The vulnerability identified as CVE-2026-68587 constitutes a structural breakdown in this access boundary. Certain administrative endpoints tasked with generating transaction metadata do not require administrative privileges. This logical flaw allows external, unauthenticated users to inspect the backend-rendered structure of private documents.

These affected endpoints include /api/block/getHeadingDeleteTransaction, /api/block/getHeadingLevelTransaction, and /api/block/getHeadingInsertTransaction. Because these APIs process arbitrary block identifiers without verifying document-level publication state, they represent a significant information disclosure risk. Organizations utilizing SiYuan in publish mode must take immediate steps to secure these interfaces.

The technical root cause of CVE-2026-68587 lies in the routing configurations of the SiYuan backend, which is implemented in Go using the Gin web framework. Access control for endpoints in SiYuan is typically regulated by middleware components. Specifically, model.CheckAuth permits access to unauthenticated or read-only users when publish mode is active, while model.CheckAdminRole restricts requests to validated workspace administrators.

In versions of SiYuan prior to v3.7.3, the router registered the three heading transaction endpoints using only the model.CheckAuth middleware. As a result, the backend treated anonymous guest readers as authorized callers for these administrative APIs. Because these handlers did not inspect the active session for an administrative role, any reader could execute the transaction generation logic.

Furthermore, the internal logic of the transaction handlers did not perform document-level publication validation. Normally, accessing a document node via /api/block/getDoc triggers checking logic that confirms whether the document is published. However, the transaction handlers resolved targeted block IDs directly from the database, rendered the corresponding node subtrees into DOM structures, and returned the output without verifying whether the source document was publicly visible.

An analysis of the source code in kernel/api/router.go confirms the insecure routing definitions before the security fix was applied. The three transaction-related endpoints were declared as follows:

ginServer.Handle("POST", "/api/block/getHeadingLevelTransaction", model.CheckAuth, getHeadingLevelTransaction)
ginServer.Handle("POST", "/api/block/getHeadingDeleteTransaction", model.CheckAuth, getHeadingDeleteTransaction)
ginServer.Handle("POST", "/api/block/getHeadingInsertTransaction", model.CheckAuth, getHeadingInsertTransaction)

Under this configuration, any incoming HTTP POST request to these paths that satisfied model.CheckAuth was forwarded directly to the respective handler functions. No secondary checks were executed to ensure that the client possessed write or administrative permissions.

To resolve this vulnerability, the development team modified the routing definitions in commit 69db783b782aea865ea70a1c5ab656e5c0f3dadb. The patch inserts the model.CheckAdminRole middleware into the chain for each endpoint:

ginServer.Handle("POST", "/api/block/getHeadingLevelTransaction", model.CheckAuth, model.CheckAdminRole, getHeadingLevelTransaction)
ginServer.Handle("POST", "/api/block/getHeadingDeleteTransaction", model.CheckAuth, model.CheckAdminRole, getHeadingDeleteTransaction)
ginServer.Handle("POST", "/api/block/getHeadingInsertTransaction", model.CheckAuth, model.CheckAdminRole, getHeadingInsertTransaction)

This change ensures that the router interceptor validates the user's role prior to invoking the core handlers. If a request originating from an unauthenticated or read-only source is detected, the Gin engine blocks execution and returns an HTTP 403 Forbidden response, mitigating the unauthorized access vector.

To exploit CVE-2026-68587, an attacker must target a SiYuan instance that has publish mode enabled and is running an affected version. The attack relies on knowing or acquiring a valid block ID associated with a heading inside a private, publish-disabled document. Block IDs are 22-character unique strings that may sometimes be harvested from cached indexes, backlinks in public documents, or sequential brute-force attempts.

Once a candidate block ID is obtained, the attacker constructs an HTTP POST request targeting one of the unprotected transaction paths. The payload is sent as a JSON object containing the target identifier, as illustrated in the following structured example:

POST /api/block/getHeadingDeleteTransaction HTTP/1.1
Host: target-instance.local
Content-Type: application/json
Connection: close
 
{
  "id": "20261012111213-abcdefg"
}

Upon receiving the request, the vulnerable server retrieves the database entry associated with the block ID 20261012111213-abcdefg. Because the request bypasses role-based verification, the server generates a deletion transaction structure. This structure includes the fully rendered HTML DOM tree of the heading and its nested child nodes. The server then responds with an HTTP 200 OK containing the private textual content within the dom key of the JSON response payload.

The impact of CVE-2026-68587 is classified as High, as reflected in its CVSS v4.0 base score of 9.2. This vulnerability directly undermines the confidentiality of unpublished workspace data. Any private document containing a heading block whose identifier is discovered or predicted can be completely reconstructed and read by unauthenticated third parties.

Because the endpoints return fully rendered DOM elements, an attacker can extract sensitive information, configuration data, intellectual property, or personal notes stored in the workspace. Since the attack requires no user interaction or specialized privileges, it is highly susceptible to automated scraping campaigns if target endpoints are exposed to the public internet.

While this flaw does not directly compromise system integrity or availability (i.e., it does not allow for file system modification or arbitrary command execution on the host OS), the complete disclosure of private notes constitutes a severe privacy breach. The overall severity depends on the sensitivity of the data managed within the affected SiYuan instance.

The definitive remediation for CVE-2026-68587 is to upgrade the SiYuan installation to version v3.7.3 or later. This release incorporates the necessary middleware controls to restrict transaction endpoints to administrative accounts. Upgrades should be prioritized for all instances deployed with public access enabled.

In environments where upgrading cannot be performed immediately, administrators should implement temporary mitigation strategies. Disabling publish mode entirely prevents external readers from accessing the API backend. Alternatively, the reverse proxy or web application firewall (WAF) can be configured to block external POST requests to the /api/block/getHeadingDeleteTransaction, /api/block/getHeadingLevelTransaction, and /api/block/getHeadingInsertTransaction endpoints.

Additionally, security teams should review and monitor sibling endpoints such as /api/block/getHeadingChildrenIDs and /api/block/getHeadingChildrenDOM. These routes continue to utilize only model.CheckAuth in the routing layer. If these handlers do not perform internal document-level publication checks before rendering blocks, they may present similar disclosure risks. Confirming that internal check routines are active for these endpoints is recommended during security audits.