CVE-2026-72800: Missing Authorization in SiYuan Personal Knowledge Management System

SiYuan is a local-first personal knowledge management application that supports a publish mode, also known as read-only mode. This configuration is designed to share specific public documents with web readers while keeping private, password-protected, or encrypted notebooks confidential. Secure implementation of this feature requires the application backend to enforce strict data-access scopes for all client-initiated queries.

An architectural authorization gap exists in versions prior to v3.7.4. The server fails to enforce publish-access validation on endpoints responsible for retrieving attribute view schemas and matching block definitions. Consequently, unprivileged remote users can cross the logical boundary separating public and private documents.

This vulnerability is classified under CWE-862 (Missing Authorization). The impact is limited to metadata and structured layout exposure, which is why it receives a CVSS v3.1 base score of 5.8. However, this exposure provides key layout parameters that can facilitate further structured information gathering.

The root cause is a failure to enforce the publish-access state (model.IsReadOnlyRoleContext) inside the business logic of specific backend APIs. This omission manifests across three distinct logical pathways in the application.

First, the /api/av/getAttributeViewKeysByID endpoint was implemented without routing through the model.CheckReadonly middleware in the server's API router. Because this middleware was omitted, unauthenticated read-only sessions could request structural database keys (avID) and retrieve descriptions, column definitions, and template vocabularies for any database.

Second, the /api/block/getBlockDefIDsByRefText endpoint was programmed to query and return block definition IDs matching a given anchor search text without verifying whether the source documents were designated as public. The function model.GetBlockDefIDsByRefText processed raw queries against the database and directly returned all matched IDs.

Third, navigation and metadata endpoints such as getBlockTreeInfos, getBlockSiblingID, and getBlockRelevantIDs blind-queried internal model helpers without validating that the targeted block ID resided inside the active user's allowed publish context. These combined flaws allowed complete block-ID mapping of private notebooks.

The remediation implemented in SiYuan v3.7.4 introduces robust validation checkpoints in the file kernel/api/block.go and updates the HTTP router in kernel/api/router.go.

In the patched version, block traversal endpoints extract the target notebook (boxID) and validate the block ID's accessibility in read-only mode using isBlockPublishAccessible. The following code snippet demonstrates the authorization logic added to block APIs:

// Patched logic ensuring publish authorization gates
func checkBlockPublishAccessInBox(c *gin.Context, id, boxID string, ret *gulu.Result) bool {
	if isBlockPublishAccessible(c, id, boxID) {
		return true
	}
	ret.Code = -1
	ret.Msg = "not found"
	return false
}
 
func isBlockPublishAccessible(c *gin.Context, id, boxID string) bool {
	if !model.IsReadOnlyRoleContext(c) {
		return true
	}
	return model.CheckBlockIdAccessableByPublishAccessInBox(c, model.GetPublishAccess(), id, boxID)
}

Additionally, the reference text querying logic was patched to sanitize the list of returned matching IDs using the filterBlockIDsByPublishAccess function. This prevents unauthenticated users from obtaining block IDs from unauthorized paths:

func getBlockDefIDsByRefText(c *gin.Context) {
	// ... payload parsing ...
	anchor := arg["anchor"].(string)
	ids := model.GetBlockDefIDsByRefText(anchor)
	ids = filterBlockIDsByPublishAccess(c, ids, "") // Filter unexposed block IDs
	// ... response building ...
}

Finally, the API routing configuration in kernel/api/router.go was updated to explicitly include the missing model.CheckReadonly middleware for the attribute view schema retrieval endpoint, preventing unauthorized API interaction:

// Router configuration fix
ginServer.Handle("POST", "/api/av/getAttributeViewKeysByID", model.CheckAuth, model.CheckReadonly, getAttributeViewKeysByID)

Exploitation of CVE-2026-72800 does not require authentication or user interaction. An attacker leverages standard HTTP POST requests to discover schema structures and enumerate valid block IDs.

To construct an ID-enumeration oracle, the attacker sends a POST request targeting /api/block/getBlockDefIDsByRefText with a generic search parameter, such as {"anchor": "confidential"}. The vulnerable server queries the global workspace database and returns a JSON array of matching block IDs, regardless of whether they belong to published notebooks or encrypted offline files.

Once the attacker possesses a target block ID, they query /api/av/getAttributeViewKeysByID to harvest structural layouts, database keys, template setups, and metadata columns. Because the middleware checks were omitted, the backend returns the database's schema layout, exposing sensitive structural properties.

The security impact of CVE-2026-72800 is a partial loss of confidentiality. Because the vulnerability only exposes structural properties (such as schemas, template parameters, and block identifiers) rather than full document content, the overall impact is limited.

However, the leakage of block IDs across the entire workspace breaks the logical partition between public and private documents. An attacker can use these harvested IDs to confirm the existence of confidential projects, analyze internal documentation structures, and build relationships between private notes.

This structural exposure serves as a reconnaissance step. An attacker can combine these enumerated identifiers with other potential application flaws or access controls to target specific, unmapped assets within the SiYuan deployment.

The recommended remediation is to upgrade the SiYuan application deployment to version v3.7.4 or later. This release enforces authorization boundaries across all affected endpoints and binds the required middleware filters.

If upgrading immediately is not possible, security administrators should implement temporary mitigation strategies. Access to administrative and data APIs can be restricted by configuring an upstream reverse proxy (such as Nginx, Apache, or Cloudflare) to block incoming external requests to specific URL prefixes:

# Example block for critical metadata endpoints at the reverse proxy
location /api/av/getAttributeViewKeysByID {
    deny all;
}
location /api/block/getBlockDefIDsByRefText {
    deny all;
}

Additionally, security teams should audit their active network logs for high volumes of POST requests to /api/block/getBlockDefIDsByRefText and /api/av/ endpoints, which may indicate automated exploitation attempts.