Missing publish-access check on getAttributeViewSearchTarget endpoint exposes database row content to unauthorized readers

The SiYuan knowledge workspace platform is vulnerable to an information exposure flaw within its database module (Attribute Views). The vulnerability, registered under GHSA-9CQF-HHRQ-7V45, permits unauthorized access to unpublished database records. This issue affects instances that host published notebooks or serve public facing web content.

To manage public content safely, the server must validate access controls before exposing any document node. The endpoint /api/av/getAttributeViewSearchTarget does not perform the required publish-access validation. Consequently, unauthenticated users can probe the backend database blocks through substring queries.

This behavior exposes sensitive cell values and row metadata from private or encrypted notebooks. An attacker with network access to the API can exploit this behavior to systematically extract data without authorization.

The vulnerability stems from a missing authorization check inside the newly introduced endpoint /api/av/getAttributeViewSearchTarget. The endpoint was implemented to support search navigation across attribute views in database rows. While it implements a basic authentication check (model.CheckAuth), it does not verify whether the targeted document block resides inside a published notebook.

When a user queries the endpoint, the application retrieves the target block ID and decrypts the underlying storage if encryption is active. The system then performs substring comparisons against all key-value entries in that database block. If any substring match is successful, the server returns the fully resolved row title and metadata.

This architecture creates a side-channel substring oracle. The application fails to restrict this API endpoint based on notebook visibility settings. As a result, an attacker can extract sensitive cell values by submitting targeted guess queries and observing the structured response.

The registration of the vulnerable endpoint in the backend router lacks access restriction middlewares. The registration logic in kernel/api/router.go appears as follows:

// Vulnerable endpoint registration
ginServer.Handle("POST", "/api/av/getAttributeViewSearchTarget", model.CheckAuth, getAttributeViewSearchTarget)

The CheckAuth handler only validates that the session is authenticated or active, but does not verify whether the specific notebook (tree.Box) containing the target block is published or accessible to the current privilege level.

The search logic inside kernel/model/attribute_view_render.go parses the attribute view and retrieves data directly from the notebook storage:

// Vulnerable block retrieval and matching logic
func GetAttributeViewSearchTarget(blockID string, keywords []string) (ret *AttributeViewSearchTarget) {
    waitForSyncingStorages()
    node, tree, _ := getNodeByBlockID(nil, blockID)
    if nil == node || nil == tree || ast.NodeAttributeView != node.Type || "" == node.AttributeViewID {
        return
    }
    // Node and tree are parsed without verifying if the notebook (tree.Box) is published
    var attrView *av.AttributeView
    var err error
    if IsEncryptedBox(tree.Box) {
        attrView, err = av.ParseAttributeViewInBox(node.AttributeViewID, tree.Box)
    } else {
        attrView, err = av.ParseAttributeView(node.AttributeViewID)
    }
    // ...

The server constructs the return payload directly using the sensitive string values if a match is found:

ret = &AttributeViewSearchTarget{
    AvID:            attrView.ID,
    DatabaseBlockID: blockID,
    NotebookID:      tree.Box,
    ItemID:          itemID,
    ValueID:         blockValue.ID,
    MatchedValueID:  match.valueID,
    MatchedKeyID:    match.keyID,
    Title:           blockValue.String(true), // Exposes the raw string content
    BoundBlockID:    blockValue.Block.ID,
    IsDetached:      blockValue.IsDetached || "" == blockValue.Block.ID,
    Keywords:        keywords,
}

To resolve this flaw, the handler must check the publish state of the requested notebook. If the notebook is not published and the request is unauthenticated, the operation must abort.

An attacker can exploit this vulnerability by executing structured HTTP POST requests against the /api/av/getAttributeViewSearchTarget endpoint. The attack does not require advanced privileges if the instance exposes public pages or operates in a multi-user environment. The process follows a systematic query pattern.

The attacker constructs a JSON request body containing a target block identifier and a series of guess strings. If any guess matches a substring within the private database record, the backend responds with the full content of the row. An example payload demonstrates this mechanism:

POST /api/av/getAttributeViewSearchTarget HTTP/1.1
Host: target.local
Content-Type: application/json
 
{
  "id": "20260726000000-privateblock",
  "keywords": ["Confidential", "Secret", "Credential"]
}

If the matching algorithm succeeds, the backend returns a JSON payload containing the field "Title": "Confidential Database Record". By iterating through alphabet characters or dictionary terms, an attacker can reconstruct full cell values.

The security impact of this vulnerability involves a partial loss of confidentiality. Because the endpoint does not modify data, integrity and availability remain unaffected. This leads to a CVSS score classification based primarily on information exposure.

Attackers can leverage this endpoint as a decryption or extraction vector for otherwise protected notes. If a database contains high-value assets such as configuration variables, tokens, or personal identifiers, these assets can be retrieved remotely. The vulnerability bypasses both folder-level permission restrictions and notebook-level database encryption once a block ID is known.

In environments where SiYuan is deployed as a public wiki, the exposure risk is elevated. Unauthenticated web crawlers or targeted actors can enumerate private block structures. This allows unauthorized parties to compile sensitive data repositories from the host system.

Remediation requires modifying the backend router and query handlers to validate document ownership and publish status. Users must upgrade to a version of SiYuan that includes server-side access control validation on all database search endpoints. Relying on client-side interface patches is insufficient because raw API requests bypass UI-level restrictions.

If immediate upgrading is not possible, administrators should disable the public publishing feature. Restricting network access to the SiYuan API using reverse proxies or firewalls also reduces the exposure vector. Restrict access exclusively to authenticated local users.

Implement security group rules that monitor traffic patterns. A high volume of requests to /api/av/getAttributeViewSearchTarget from unauthenticated IP addresses indicates active scanning. Security teams should inspect logs for unauthorized calls to this specific endpoint.