CVE-2026-72797: Missing Authorization in SiYuan Notebook Metadata Endpoint

SiYuan is an open-source, self-hosted personal knowledge management system designed for secure note-taking. It features end-to-end encryption for individual notebooks, allowing users to secure sensitive contents locally or in private cloud instances. To manage these encrypted states, the application relies on an internal API kernel that responds to queries regarding structural configurations.

The vulnerability is classified under CWE-862 (Missing Authorization) and resides in the handling of the /api/notebook/getEncryptedNotebookStatus endpoint. This endpoint is designed to expose metadata indicating which notebooks are encrypted and their current cryptographic lock states. Due to a missing role-based middleware validation, the application fails to restrict access to authenticated administrative accounts.

As a consequence, unprivileged read-only users, publish-mode configurations, and anonymous readers can query this path. This grants external observers access to sensitive structural layout information without authenticating as an administrator. The exposed data includes absolute notebook identifiers, plain-text notebook titles, and internal lock states managed in the system memory.

The backend kernel of SiYuan is written in Go and utilizes the Gin web framework to handle routing and request dispatching. Route configurations are defined in kernel/api/router.go. In this routing table, specific handler functions are paired with authentication and authorization middlewares to enforce security boundaries.

In versions prior to v3.7.4, the route registration for /api/notebook/getEncryptedNotebookStatus only executed the model.CheckAuth middleware. This middleware verifies that the incoming request is associated with a valid session context or that the application is running in an environment where authentication requirements are globally bypassed, such as public reading modes. It does not evaluate the specific privileges or roles associated with the requesting entity.

Because the administrative validation middleware model.CheckAdminRole was omitted from this specific route, any user session containing the RoleReader or RoleEditor role could successfully resolve the request. Additionally, if the instance was configured to allow public-access readers, unauthenticated external actors could trigger the endpoint, bypassing the logical isolation of administrative configuration tools.

The structural difference between the vulnerable and secure configurations demonstrates how the routing engine was failing to enforce policy constraints. In the vulnerable version of the codebase, administrative endpoints such as password changes were protected by multiple layers of middleware, while the status checking endpoint remained unguarded.

// Vulnerable Route Configuration in kernel/api/router.go
ginServer.Handle("POST", "/api/notebook/lockNotebook", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, lockNotebook)
ginServer.Handle("POST", "/api/notebook/unlockAndOpenNotebook", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, unlockAndOpenNotebook)
ginServer.Handle("POST", "/api/notebook/changeMasterPassword", model.CheckAuth, model.CheckAdminRole, model.CheckReadonly, changeMasterPassword)
// The line below lacks the model.CheckAdminRole middleware
ginServer.Handle("POST", "/api/notebook/getEncryptedNotebookStatus", model.CheckAuth, getEncryptedNotebookStatus)

The corresponding security patch resolved this flaw by inserting model.CheckAdminRole into the execution chain of the target handler. This forces the Gin router to evaluate the user role before passing control to the final business logic layer.

// Patched Route Configuration in kernel/api/router.go
ginServer.Handle("POST", "/api/notebook/getEncryptedNotebookStatus", model.CheckAuth, model.CheckAdminRole, getEncryptedNotebookStatus)

To ensure the validity of this patch, developers implemented explicit unit tests to assert the behavior of the endpoint against varying authorization levels. This test verifies that RoleReader and RoleEditor sessions yield a 403 Forbidden status code, while administrative sessions return an HTTP 200 OK status with successful payload delivery. This programmatic enforcement prevents regressions in future release branches.

An attacker attempting to exploit this vulnerability does not require highly specialized tools. Because the handler responds to standard POST requests, a simple payload containing an empty JSON body sent via curl or a scripting library is sufficient to extract the sensitive information.

POST /api/notebook/getEncryptedNotebookStatus HTTP/1.1
Host: target-siyuan.local:6806
Content-Type: application/json
Cookie: s_session=low_privilege_reader_cookie
 
{}

Upon receiving this request, a vulnerable instance parses the empty JSON structure and returns a complete list of encrypted notebooks registered within the installation directory. The response body reveals structural information that is critical for further targeted attacks.

{
  "code": 0,
  "msg": "",
  "data": {
    "notebooks": [
      {
        "id": "20260724123045-8abc123",
        "name": "Proprietary Research & IP",
        "closed": false
      }
    ]
  }
}

The presence of the plain-text notebook name combined with its unique system ID exposes what files are present on the host filesystem. Furthermore, the boolean closed property discloses whether the decrypted key currently resides in active server memory, hinting at user activity and session status.

Although this vulnerability does not allow direct remote code execution or file modification, the exposure of configuration and directory names is highly valuable for reconnaissance. Attackers can leverage the leaked notebook titles to understand the contents and operations of the host environment, locating high-value data targets within the system.

The unique IDs retrieved from the vulnerable endpoint map directly to the directory structures stored on disk or within the synchronized cloud storage buckets. If an attacker has local access or read-only access to the file storage but lacks decryption credentials, mapping these folder hashes to human-readable names facilitates targeted offline recovery efforts.

Under CVSS v4.0, the vulnerability yields a base score of 6.9, reflecting its impact on the system's confidentiality boundaries. In situations where SiYuan is run as a collaborative knowledge base for enterprise teams, this information disclosure compromises the security isolation boundaries expected between readers and system administrators.

The definitive resolution for CVE-2026-72797 is upgrading the SiYuan installation to version v3.7.4 or later. For environments running SiYuan within containerized runtimes, administrators should verify that the application tag is locked to a non-vulnerable version rather than relying on unpinned versions.

In cases where immediate upgrades are restricted by organizational patch management procedures, network isolation controls must be enforced. Administrators should configure local firewall rules to restrict access to port 6806, ensuring that only trusted administrator loopback IP addresses or designated VPN segments can reach the application's underlying API interface.

To identify potential exploitation attempts in web application logs, security operations center (SOC) teams should analyze requests directed to /api/notebook/getEncryptedNotebookStatus. Multiple requests from client IP addresses associated with non-administrative activities, or sessions that suddenly trigger an HTTP 403 status after a patch is applied, should be treated as potential reconnaissance activity.