CVE-2026-72803: Information Disclosure via Missing Authorization in SiYuan API

SiYuan is an open-source, privacy-focused personal knowledge management system that utilizes a local-first block-oriented architecture. The software allows users to structure documents into individual, nested components called blocks, which are stored in a database backend. To support public-facing applications such as personal blogs or knowledge wikis, SiYuan contains features to selectively publish documents or restrict access via passwords and disabled-publish flags.

The attack surface lies in the Web API endpoints exposed by the Go-based backend. Specifically, the endpoints responsible for retrieving block-level attributes fail to check the authorization status of the parent document. These endpoints, namely /api/attr/getBlockAttrs and /api/attr/batchGetBlockAttrs, are accessible over the network and allow clients to query metadata about database blocks.

Due to a missing authorization check, classified under CWE-862, unauthenticated remote attackers can directly query these endpoints to read block attributes from restricted, password-protected, or completely unpublished documents. The vulnerability bypasses the document-level publication restrictions enforced in the standard user interface. The system returns the sensitive attributes if the attacker can present the target block ID.

The impact of this vulnerability is limited to information disclosure of block-level attributes. It does not permit the modification of data or the execution of arbitrary commands. However, because custom block attributes often contain metadata, memos, and structural design notes, the disclosure can lead to substantial exposure of proprietary information.

The fundamental flaw stems from an incomplete access control design in the Go backend controller layer. SiYuan implements document accessibility filters to determine whether a reader has authorization to access specific document trees. These restrictions are defined inside the model.PublishAccess configuration structure, which tracks whether a document is disabled from publishing or password-protected.

When a standard request for a document occurs, the application verifies the requester's permissions against the parent document ID. If the document is marked as disabled-publish or requires a password that has not been supplied, the backend blocks the query. However, the block attribute subsystem represents a secondary query mechanism that operates independently of the document-rendering pipeline.

Each block contains an Internal Attribute Layout (IAL) structure that holds metadata. These attributes include human-readable names, custom aliases, private memos, and arbitrary user-defined key-value attributes. The underlying database stores these key-value pairs associated with the block ID, without dynamically maintaining the authorization context of the parent document.

The vulnerable endpoints /api/attr/getBlockAttrs and /api/attr/batchGetBlockAttrs are mapped directly to database queries. Prior to version 3.7.4, the controller functions invoked the SQL query interface directly using the attacker-supplied block ID. The server failed to trace the block ID back to its parent document ID and did not execute the publication-access validation checks, leading to a complete bypass of the document-level security posture.

The core vulnerability was located in the file kernel/api/attr.go. In affected versions prior to v3.7.4, the API handlers did not invoke any filter functions on the incoming user parameters. The data was passed directly to the database layer as shown below.

// Vulnerable implementation of batchGetBlockAttrs
func batchGetBlockAttrs(c *gin.Context) {
    // ... input extraction ...
    for _, id := range ids {
        idList = append(idList, id.(string))
    }
    // Direct database query without checking block permissions
    ret.Data = sql.BatchGetBlockAttrs(idList)
}

To resolve this issue, the patch introduced in commit 229fdffd7e4afdef543d4d8495657fda8a369400 implements explicit filtering. For single-block requests, the handler now calls checkBlockPublishAccess. For batch requests, it utilizes filterBlockIDsByPublishAccess.

// Patched implementation of batchGetBlockAttrs
func batchGetBlockAttrs(c *gin.Context) {
    // ... input extraction ...
    for _, id := range ids {
        idList = append(idList, id.(string))
    }
    // Patch: Filter IDs based on current session publish-access permissions
    idList = filterBlockIDsByPublishAccess(c, idList, "")
    ret.Data = sql.BatchGetBlockAttrs(idList)
}

The function checkBlockPublishAccess determines whether the parent document associated with the specified block ID is accessible to the current session role. If the document is restricted and the current session is unauthenticated, the request terminates immediately, preventing execution of the database call. In the batch handler, the filterBlockIDsByPublishAccess helper removes restricted block IDs from the slice, ensuring that only public or authorized blocks are queried in the database.

Exploitation of CVE-2026-72803 does not require active session authentication or complex delivery payloads. The primary prerequisite is the acquisition or deduction of valid block IDs. Attackers can obtain target block IDs through several vectors, such as scraping public assets, analyzing client-side Javascript code, extracting historical search engine caches, or observing link paths shared in public forums.

Once an attacker possesses a target block ID, they can construct a structured JSON request targeting the endpoint /api/attr/getBlockAttrs. The application parses the request payload and processes the query under the security context of the current requester, which defaults to the lowest privilege level if no session tokens or API keys are present.

An example exploitation query targeting the single-block endpoint uses a standard HTTP POST method:

POST /api/attr/getBlockAttrs HTTP/1.1
Host: target.siyuan.local
Content-Type: application/json
 
{
  "id": "20260724000002-secret1"
}

The server responds with the requested attribute values, completely bypassing the document-level password protect configuration or disabled-publish status. If the block contains sensitive internal variables, names, or structural maps, these values are returned within the data field of the JSON response payload.

The security consequences of CVE-2026-72803 are classified as moderate, yielding a CVSS v4.0 base score of 6.9. The main impact is the loss of confidentiality for block-level metadata. Because this vulnerability does not allow an attacker to write, modify, or delete database elements, system integrity and availability remain unaffected.

Although block content is not directly returned by this endpoint, block attributes often contain substantial exposure risks. Users frequently leverage block-level memos to store design specifications, developer tasks, or security observations. Furthermore, custom aliases and user-defined fields can expose application credentials, external reference links, or system configuration keys.

The CVSS v3.1 rating is calculated at 5.8, reflecting network-based, low-complexity, unauthenticated access. The subsequent system confidentiality impact is categorized as low because the data leakage is confined to the metadata properties of the blocks rather than the entire document block-tree contents.

There is currently no evidence of active exploitation of this vulnerability in the wild. It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the EPSS score is 0.00237, which indicates a low probability of near-term exploitation. Nonetheless, self-hosted instances configured for public distribution remain exposed until patched.

The recommended and most secure remediation strategy is to upgrade the SiYuan application to version v3.7.4 or later. This release integrates the authorization check helper functions directly into the vulnerable API pathways in kernel/api/attr.go. Users deploying SiYuan via Docker should pull the latest image version and recreate the container to apply the patch.

If immediate patching is unfeasible due to deployment constraints or change-control freezes, administrators can implement network-level workarounds. Using a reverse proxy such as Nginx or Caddy, administrators should block external access to the vulnerable API routes. The following Nginx directive restricts POST requests to these endpoints to authorized IP addresses:

location ~* ^/api/attr/(getBlockAttrs|batchGetBlockAttrs)$ {
    allow 192.168.1.0/24;
    deny all;
    proxy_pass http://siyuan_backend;
}

Additionally, content authors should review the distribution of sensitive data within self-hosted instances. Removing sensitive notes from block-level memos and custom metadata keys in workspaces shared in public-facing modes minimizes exposure. Regular log analysis targeting HTTP requests to the /api/attr/ namespace helps detect scanning and exploit attempts.