CVE-2026-72798: Missing Authorization and Information Disclosure in SiYuan renderAttributeView

SiYuan is a local-first personal knowledge management system designed to support complex databases, relation attributes, and page-publishing features. When deployed in publish mode, the server is designed to enforce access control boundaries, ensuring that anonymous web readers can only view explicitly authorized, public-facing database blocks.

Prior to version v3.7.4, the API endpoint responsible for rendering database view attributes, 'renderAttributeView', suffered from critical security flaws that compromised these access controls. Specifically, the component failed to adequately validate the authorization context when rendering row attributes and serializing nested cell relationships.

These design oversights allowed anonymous remote users to bypass publish-access boundaries. By querying public database views containing references to private tables, users could extract confidential records from hidden or password-protected databases.

The first security flaw stems from a fail-open logical assumption in the primary filter function 'FilterViewByPublishAccess'. To verify row-level access permissions, the system checked the block identifier stored in the first column of each row ('row.Cells[0]'). It retrieved the block tree state and verified its public availability.

If the database layout was modified or reordered such that the first column was a non-block type—such as a selection, text, relation, or rollup field—the cell did not contain a valid block ID. Consequently, the block tree lookup returned a 'nil' state, causing the access check to return true and bypass authorization checks entirely.

The second logical flaw is located in the serialization of 'Relation' and 'Rollup' database attributes. These fields do not merely store pointers to other tables; they encapsulate cached copies of structures like 'ValueRelation' and 'ValueRollup', which contain raw content from the target databases. Because the rendering process failed to recursively inspect and sanitize these complex nested structs, confidential metadata was exposed to unauthorized users.

The vulnerable implementation in 'renderAttributeView' loaded data blocks without validating that the targeted relation database was accessible to the client. The fix introduces a multi-layered security boundary by integrating recursive, layout-aware validation.

Below is a simplified representation of the recursive validation loop introduced in the patch to intercept unauthorized cells:

// Patched logic evaluating layout and filtering cell values
func (filter *attributeViewPublishAccessFilter) filterViewable(attrView *av.AttributeView, viewable av.Viewable) {
    if nil == viewable {
        return
    }
 
    switch viewable.GetType() {
    case av.LayoutTypeTable:
        table := viewable.(*av.Table)
        filter.filterGroupValue(attrView, table.BaseInstance)
        for _, row := range table.Rows {
            if nil == row {
                continue
            }
            for _, cell := range row.Cells {
                if nil == cell {
                    continue
                }
                // Deeply evaluates authorization context per cell
                filter.filterBaseValue(attrView, row.ID, cell.BaseValue)
            }
        }
    }
}

When encountering relationship properties, the system now enforces a strict verification check against the target view. If authorization to the related target view is not present, the content is replaced with empty structures via the 'clearAttributeViewSensitiveValue' function:

func clearAttributeViewSensitiveValue(value *av.Value) *av.Value {
    ret := cloneAttributeViewSensitiveValue(value)
    switch value.Type {
    case av.KeyTypeRelation:
        // Clears out potentially sensitive relations
        ret.Relation = &av.ValueRelation{}
    case av.KeyTypeRollup:
        // Clears out potentially sensitive rollups
        ret.Rollup = &av.ValueRollup{}
    }
    return ret
}

This recursive approach prevents parent database views from leaking cached records belonging to restricted or password-protected datasets.

An attacker can exploit this vulnerability with network-level access to the SiYuan web interface. The prerequisites are minimal: the attacker must locate a published, public-access database view that contains relation fields linking to protected databases.

To retrieve unauthorized cell values, the attacker initiates a direct POST request to the '/api/av/renderAttributeView' endpoint specifying the public attribute view identifier. The request payload matches the following format:

POST /api/av/renderAttributeView HTTP/1.1
Host: target-siyuan-instance:6806
Content-Type: application/json
 
{
  "id": "public-attribute-view-id",
  "blockID": "public-block-id"
}

Because the vulnerable server fails to recursively sanitize relations, the response JSON includes the serialized 'Relation' and 'Rollup' structures containing information retrieved from the linked, protected databases. This bypasses the access controls configured on the target databases.

Additionally, if the first column layout has been reordered to a non-block type, sending a request to view that specific table bypasses all row-level authorization entirely, exposing the entire table contents to unauthenticated visitors.

The following sequence diagram outlines the data flow in an exploitation scenario:

The security impact of CVE-2026-72798 is high due to the exposure of confidential records from private repositories. The vulnerability scores 9.2 under CVSS v4.0 and 8.6 under CVSS v3.1, reflecting its critical nature.

Attackers can leverage this bypass to harvest intellectual property, access credentials, personal documentation, or internal lists that users assumed were secured behind authorization parameters or password prompts.

Because SiYuan is often used to maintain integrated personal or organizational wikis, exposing database relationship structures represents a complete breach of the confidentiality model. There is no impact on integrity or availability, as the endpoint does not process state-modifying requests.

To remediate the vulnerability, administrators must update their SiYuan installations to version v3.7.4 or later. This version introduces comprehensive filtering, validating both top-level and recursive relation paths.

In environments where immediate software updates are not feasible, administrators should restrict network exposure of the SiYuan server. Ensure that port 6806 is bound exclusively to local network interfaces or positioned behind a robust reverse proxy that enforces secondary authentication layers.

Additionally, administrators can mitigate the leak vector by temporarily deleting active 'Relation' or 'Rollup' attributes that link public databases to private or sensitive repositories.