CVE-2026-68584: Authentication Bypass via Auxiliary Content Endpoints in SiYuan

SiYuan incorporates a publish-mode component designed to share notebook content over HTTP, typically bound to port 6808. This module supports multiple document access levels, including public, private, hidden, forbidden, and protected. The 'protected' access level allows notes to be listed publicly in the file tree while enforcing a password challenge prior to revealing their structural content.\n\nThe primary path for content retrieval, /api/filetree/getDoc, properly invokes the internal access-validation engine to enforce authentication checks. However, multiple secondary and auxiliary endpoints responsible for block-level data retrieval lack these essential authorization routines. This architectural inconsistency forms the core of the vulnerability, classified under CWE-288: Authentication Bypass Using an Alternate Path or Channel.\n\nBy calling these unauthenticated endpoints directly, any remote attacker can circumvent the primary password check. The only technical prerequisite is discovering the structural identifier of the target block or heading. Once this identifier is obtained, the attacker can retrieve the full rendered Document Object Model (DOM) of the protected resource without authentication.

The root cause of this vulnerability lies in an inconsistent authorization model across the SiYuan Go-based kernel. In a secure architecture, any endpoint exposing structural children or parent nodes must resolve the master document's permission model. In SiYuan, however, document authorization is split into distinct logical validation paths that are not globally applied.\n\nWhen a user requests a document through the standard UI path, the backend router executes the FilterContentByPublishAccess procedure. This function evaluates the active session state against the password-protection policy of the document. If no valid password-session cookie is transmitted, the server stops execution and returns an empty structural placeholder.\n\nConversely, the auxiliary block and heading endpoints, such as /api/block/getHeadingChildrenDOM and /api/block/getHeadingChildrenIDs, only execute basic role authentication checks. These handlers verify that the system is configured to serve published notes, but they do not trace the requested block ID back to its parent document or evaluate the document's password policy. Consequently, any request containing a valid block identifier is processed, and the system renders and returns the confidential content.\n\nTo compound this authorization flaw, the application's search engine exposes structural identifiers. Although the search endpoint /api/search/searchEmbedBlock implements post-query sanitization, it only redacts the literal text content. The system fails to sanitize the metadata fields, returning the exact block identifiers associated with the matching query results and allowing an attacker to map the target document's layout.

The vulnerability is resolved in commit 2d069dce84a25c959ef0093c72c98e05778ef218 by integrating the authorization helper directly into the vulnerable API endpoints. Prior to this patch, handlers in kernel/api/block.go retrieved database blocks without validating parent document metadata.\n\nThe patch introduces a renamed, unified helper function checkBlockPublishAccess that resolves the target block to its root document and evaluates the authorization state. The following code comparison highlights how the vulnerability was addressed in kernel/api/block.go:\n\ndiff\n-func getHeadingChildrenIDs(c *gin.Context) {\n+func getHeadingChildrenIDs(c *gin.Context) {\n \t// ... context bindings\n \tid := arg["id"].(string)\n+\tif !checkBlockPublishAccess(c, id, ret) {\n+\t\treturn\n+\t}\n \tids := model.GetHeadingChildrenIDs(id)\n \tret.Data = ids\n }\n\n-func getHeadingChildrenDOM(c *gin.Context) {\n+func getHeadingChildrenDOM(c *gin.Context) {\n \t// ... context bindings\n \tid := arg["id"].(string)\n+\tif !checkBlockPublishAccess(c, id, ret) {\n+\t\treturn\n+\t}\n \tremoveFoldAttr := true\n \t// ... DOM parsing and retrieval\n }\n\n\nBy adding checkBlockPublishAccess directly into getHeadingChildrenIDs and getHeadingChildrenDOM, the system blocks requests at the routing layer if the requester has not bypassed the primary password gate. The helper function queries the parent document ID associated with the target block, validates the cookie session, and aborts processing if the validation fails.\n\nWhile the patch secures these specific endpoints, it highlights the challenges of implementing a robust, centralized permission model in hierarchical databases. Security teams should ensure that any newly added API endpoints retrieving block metadata or child structures explicitly inherit this security helper to prevent future bypass variants.

An attack against a vulnerable SiYuan instance follows a multi-stage approach, leveraging the metadata leakage in the search API to populate the parameters for the unauthorized block-retrieval calls. This sequence is illustrated in the architectural diagram below:\n\nmermaid\ngraph LR\n Attacker["Attacker (Unauthenticated)"] -->|Step 1: Discover Doc ID| FileTreeAPI["/api/filetree/listDocsByPath"]\n Attacker -->|Step 2: Query Search| SearchAPI["/api/search/searchEmbedBlock"]\n SearchAPI -->|Step 3: Extract Metadata| Attacker\n Attacker -->|Step 4: Request Content| HeadingAPI["/api/block/getHeadingChildrenDOM"]\n HeadingAPI -->|Step 5: Bypass Gate| Attacker\n\n\nIn the first phase of the attack, the adversary queries the public document listing interface to discover the unique ID of the password-protected note. Although the document's content is blocked, its root identifier remains visible to assist with client-side UI rendering. The attacker then targets the search API to extract internal block IDs by running a query scoped to the discovered document ID:\n\nhttp\nPOST /api/search/searchEmbedBlock HTTP/1.1\nHost: target-siyuan-instance:6808\nContent-Type: application/json\n\n{\n "stmt": "SELECT * FROM blocks WHERE root_id='PROTECTED_DOC_ID' AND type='h'"\n}\n\n\nIn response, the server returns an array of matching search results. While the content field is redacted with a placeholder string, the metadata fields remain fully intact. The attacker extracts the raw block and heading identifiers, such as LEAKED_HEADING_ID_999, directly from the JSON payload.\n\nWith these leaked identifiers, the attacker bypasses the password page by targeting the auxiliary endpoint directly. This request avoids the standard authentication routines and successfully retrieves the target block's fully rendered HTML DOM:\n\nhttp\nPOST /api/block/getHeadingChildrenDOM HTTP/1.1\nHost: target-siyuan-instance:6808\nContent-Type: application/json\n\n{\n "id": "LEAKED_HEADING_ID_999"\n}\n\n\nThe server processes this request and returns an HTTP 200 response containing the sensitive data. By repeating this process for each leaked block identifier, the attacker can systematically reconstruct the entire protected document.

The exploitation of CVE-2026-68584 results in a complete loss of confidentiality for any document hosted on a public SiYuan server. Because the application is designed to function as a personal knowledge base, protected files often contain sensitive information, including API keys, network diagrams, internal documentation, or personal records. Exposure of these files can lead to further compromises of connected infrastructure.\n\nThe CVSS v3.1 score is rated at 8.6 (High), reflecting the low barrier to entry for potential attackers. The vulnerability requires no prior authentication, does not depend on user interaction, and is simple to execute. The scope metric is classified as Changed (S:C) because accessing block-level metadata allows the attacker to bypass document-level authorization boundaries.\n\nFrom a threat intelligence perspective, while the vulnerability is not currently listed in the CISA KEV catalog, public proof-of-concept exploits are available. Security teams should treat any internet-exposed SiYuan server running publish mode on a vulnerable version as highly susceptible to automated scanning and opportunistic data harvesting.

The primary and recommended remediation is to upgrade the SiYuan application to version 0.0.0-20260721020826-2d069dce84a2 or later. This release integrates the necessary authorization validation checks across all block-level retrieval routes, mitigating the alternate-path authentication bypass.\n\nIf an immediate upgrade is not possible, organizations should implement compensating network controls. Deploying a reverse proxy, such as Nginx or Apache, in front of the SiYuan publish port (typically 6808) allows administrators to restrict access to sensitive API paths. Below is a sample Nginx rule set designed to block requests to the vulnerable endpoints from unauthenticated networks:\n\nnginx\nserver {\n listen 80;\n server_name siyuan.internal;\n\n location ~* ^/api/block/getHeading(Children|Delete|Level|Insert) {\n # Restrict these endpoints to internal networks only\n allow 192.168.1.0/24;\n deny all;\n proxy_pass http://127.0.0.1:6808;\n }\n\n location / {\n proxy_pass http://127.0.0.1:6808;\n }\n}\n\n\nAdditionally, administrators can mitigate the risk by disabling the public publish mode entirely if it is not actively required. By enforcing strict firewall rules that restrict access to port 6808 to trusted VPN tunnels or local loopback interfaces, the attack surface is significantly reduced. This step prevents remote attackers from interacting with either the search or block APIs.