CVE-2026-72806: Missing Authorization in SiYuan Attribute View Rendering Leads to Information Disclosure

SiYuan is an open-source personal knowledge management platform that features dynamic database and attribute views, including tables, kanban boards, and gallery layouts. To support collaboration and sharing, the platform includes a 'Publish Mode' which allows document owners to expose specific spaces or documents to external readers. Within this model, administrators can assign protection tiers to restrict access, such as assigning a password-protected tier to confidential documents.

However, a critical security boundary flaw exists in how these views interact with document-level permissions. When an external reader queries a published database view, the platform is designed to filter out any content belonging to unauthorized or restricted pages. Under CVE-2026-72806, the component tasked with executing this filtering logic failed to evaluate and enforce password-protection policies.

As a consequence, unauthenticated network attackers can interact with backend rendering routes to pull sensitive database items. By querying these exposed endpoints, an attacker can extract valuable database schema rows, block identifiers, titles, and custom column attributes linked to password-protected files. The vulnerability lies within the logic of FilterViewByPublishAccess inside the kernel model, creating a direct pathway to unauthorized information disclosure.

The root cause of CVE-2026-72806 is localized to the FilterViewByPublishAccess function inside the kernel/model/publish_access.go file. The primary purpose of this function is to iterate over database layouts—specifically Table, Gallery, and Kanban views—and filter out items that the unauthenticated user should not see. It attempts to enforce the configuration rules determined by the system's publish access policy.

In vulnerable versions of the application, the filtering logic only verified if a document path was explicitly excluded via the publish-ignore mechanism. This check was performed using the CheckPathAccessableByPublishIgnore helper function. If a document did not belong to the explicit ignore list, the system presumed it was fully accessible, ignoring the secondary security checks governing password-protected documents.

This design created a logic gap because password restrictions are handled independently from publish-ignore lists. When a document is protected by a password, its parent or child block trees still reside in memory and can be accessed via attribute views. Because the backend loops for Table, Gallery, and Kanban structures did not interface with the password validation module, the server would marshal the protected rows into JSON and return them to the client.

An analysis of the vulnerable source code highlights the custom iteration and insecure validation logic. Each database layout type had a dedicated loop that parsed metadata and constructed the response dataset manually. Below is an excerpt of the vulnerable table layout filtering loop:

for _, row := range table.Rows {
    var bt *treenode.BlockTree
    if len(row.Cells) > 0 {
        if row.Cells[0].Value.Block != nil {
            id := row.Cells[0].Value.Block.ID
            if id != "" {
                bt = treenode.GetBlockTree(id)
            }
        }
    }
    if bt != nil {
        // Vulnerable: Only evaluates ignore-lists, missing password checks
        if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) {
            row = nil
        }
    }
    if row != nil {
        filteredRows = append(filteredRows, row)
    }
}

To resolve this vulnerability, developers removed the redundant, manual checking logic within each layout block in commit 768427f20f13bbd8dc4effa8aa4e1d09a7741bf4. It was replaced with a call to a unified helper function named checkAttributeViewItemAccessableByPublishAccess. The patched logic redirects the block validation to the centralized security evaluator:

func checkAttributeViewItemAccessableByPublishAccess(c *gin.Context, publishAccess PublishAccess, item av.Item) bool {
    if nil == item {
        return false
    }
    blockValue := item.GetBlockValue()
    if nil == blockValue || blockValue.IsDetached || nil == blockValue.Block || "" == blockValue.Block.ID {
        return true
    }
    // Centralized validator enforcing path ignores AND password restrictions
    return CheckBlockIdAccessableByPublishAccess(c, publishAccess, blockValue.Block.ID)
}

This modification ensures that the core CheckBlockIdAccessableByPublishAccess utility evaluates whether the request context has been authorized with the necessary password credentials before allowing the data to be returned.

Exploiting CVE-2026-72806 does not require prior administrative or user-level authentication. The attack takes place entirely over HTTP/S and can be completed by any network-adjacent or remote unauthenticated user. The target application must have public 'Publish Mode' enabled with a database view containing entries linked to password-protected documents.

An attacker begins the exploit sequence by locating a public SiYuan instance and mapping its rendered components. Instead of interacting with the frontend web interface, the attacker sends a crafted API request directly to the backend database rendering endpoint. For example, an HTTP POST request targeting /api/av/renderAttributeView can be sent with parameters referencing the target view identifier.

When the backend processes the request, the flawed FilterViewByPublishAccess module parses the view contents. Because the verification routine only removes elements matching explicit ignore paths, it leaves items that require password validation untouched. The backend generates a complete JSON response containing the properties, titles, block IDs, and custom attributes of the password-protected pages.

The impact of CVE-2026-72806 is classified primarily as a loss of confidentiality. Because SiYuan serves as a personal and enterprise knowledge repository, databases often contain sensitive intellectual property, operational logs, personal credentials, and client tracking details. Exposing database properties of password-protected documents defeats the core authorization control of the system.

While the vulnerability does not directly permit arbitrary code execution or data modification, the metadata disclosure is highly critical. Exposed data elements include precise block identifiers, primary document titles, and schema attributes such as text fields, select dropdowns, custom dates, and attached file paths. In many database setups, the attributes themselves hold the bulk of the actual content, rendering the password protection on the sub-document effectively useless.

From a risk perspective, this vulnerability has a CVSS v3.1 score of 5.8 (Medium) and a CVSS v4.0 score of 6.9. The changed scope parameter in CVSS v3.1 reflects how a failure in the rendering mechanism directly compromises the access controls of underlying linked document resources. Because the exploitation requirements are minimal, organizations exposing SiYuan instances to the public internet face a heightened risk of targeted reconnaissance and data scraping.

The definitive remediation for CVE-2026-72806 is upgrading the SiYuan application to version v3.7.4 or higher. The official security patch modifies the core kernel logic, ensuring that all database views leverage the unified validation utility. This change successfully prevents unauthenticated API callers from receiving sensitive database properties without supplying valid password verification tokens.

If upgrading immediately is not feasible, administrators should apply defensive network mitigations. Restricting access to the SiYuan container or server via IP address whitelisting or establishing a Virtual Private Network (VPN) requirement drastically limits the attack surface. Disabling 'Publish Mode' entirely in the application configuration will also mitigate the risk by cutting off public exposure to the rendering routes.

For instances where public access is necessary, administrators should audit published database views. Ensure that sensitive rows pointing to password-protected pages are either manually removed from published database objects or explicitly placed on the publish-ignore list. Because the ignore list check is evaluated correctly by vulnerable code versions, placing these elements on the ignore list will successfully hide them from unauthenticated readers.