CVE-2026-68585: Metadata Disclosure via Missing Authorization in SiYuan API

SiYuan is an open-source personal knowledge management system that utilizes a local graph-based database structure to organize documents as blocks. To support collaboration and public knowledge sharing, the application includes a "publish mode" feature. This mode allows host administrators to selectively publish specific folders, notebooks, or individual documents to the web while keeping other records strictly private. This design establishes a trust boundary separating authorized readers from anonymous or untrusted external clients.

The vulnerability identified as CVE-2026-68585 represents a critical breakdown in this trust boundary. In versions prior to v3.7.3, the system failed to enforce consistent authorization checks across all metadata retrieval endpoints. Specifically, the API endpoint designed to fetch information about structural blocks, /api/block/getBlockInfo, lacked any logic to verify if the parent document of a requested block was authorized for public distribution.

As a result, unauthenticated network attackers can query arbitrary block identifiers and bypass the intended access restrictions. This exposure leaks structural, organizational, and context-sensitive metadata associated with private files. This lack of access verification qualifies as a Broken Object Level Authorization (BOLA) vulnerability, categorized under CWE-862 (Missing Authorization).

The root cause of CVE-2026-68585 is located in the backend implementation of the block-querying architecture of the SiYuan kernel. The application utilizes the Gin web framework in Go to route incoming HTTP POST requests to various API handlers. These handlers interact with the database to serve raw node details, page metadata, and structural layout information. The system distinguishes read-only reader sessions from administrative ones by checking the request context via model.IsReadOnlyRoleContext.

While sibling endpoints such as /api/block/getDocsInfo implemented basic sanitization or output filtering, /api/block/getBlockInfo and /api/block/getDocInfo directly mapped incoming parameters to internal database lookups. The application parsed the target block identifier directly from the user's JSON payload without executing an authorization query. The database subsequently fetched the corresponding record, parsed the block tree, and returned the metadata directly to the caller.

The critical omission lies in the absence of an access control gate that validates the structural context of the block against the current publication configuration. In SiYuan, documents can be marked with a publish-forbidden flag or excluded from the public notebooks list entirely. However, the system evaluated authorization at the routing level or document-list level, completely neglecting object-level access verification when retrieving individual block records. Consequently, knowing or guessing a block identifier was sufficient to retrieve its associated metadata, regardless of its publication status.

The vulnerability was resolved in commit ffde3b21eca49ae98828747ca126581a553cce8b by introducing a central validation helper function named checkBlockInfoPublishAccess and integrating it across the affected API handlers in the kernel/api/block.go file. This helper intercepts incoming requests to enforce access policies prior to database execution.

The implementation of checkBlockInfoPublishAccess is structured as follows:

func checkBlockInfoPublishAccess(c *gin.Context, id string, ret *gulu.Result) bool {
	// If the current request context is not a read-only role, bypass access verification
	if !model.IsReadOnlyRoleContext(c) {
		return true
	}
 
	// Retrieve the active publication settings of the application
	publishAccess := model.GetPublishAccess()
	// Check if the specific block ID is accessible under the retrieved publish access rules
	if model.CheckBlockIdAccessableByPublishAccess(c, publishAccess, id) {
		return true
	}
 
	// Deny access if verification fails, setting error code and language-mapped message
	ret.Code = -1
	ret.Msg = fmt.Sprintf(model.Conf.Language(15), id)
	return false
}

This helper is applied at the entry points of both getBlockInfo and getDocInfo. For example, in getBlockInfo, the code block was modified to prevent further processing if the validation fails:

 func getBlockInfo(c *gin.Context) {
 	ret := gulu.Ret.NewResult()
 	defer c.JSON(http.StatusOK, ret)
 
 	var arg map[string]any
 	if err := c.ShouldBindJSON(&arg); err != nil {
 		ret.Code = -1
 		ret.Msg = err.Error()
 		return
 	}
 
 	id := arg["id"].(string)
+	if !checkBlockInfoPublishAccess(c, id, ret) {
+		return
+	}
 
 	// 仅在此处使用带重建索引的加载函数，其他地方不要使用
 	var tree *parse.Tree

Furthermore, the batch retrieval handler getDocsInfo was refactored to perform inline filtering of requested identifiers. Instead of building the list of query targets blindly, the updated logic validates each block ID individually. If the execution context is read-only, any unauthorized block ID is omitted from the processing slice, and the handler exits early if the resulting list is empty:

 	idsArg := arg["ids"].([]any)
+	isReadOnlyRole := model.IsReadOnlyRoleContext(c)
+	var publishAccess model.PublishAccess
+	if isReadOnlyRole {
+		publishAccess = model.GetPublishAccess()
+	}
 	var ids []string
 	for _, id := range idsArg {
-		ids = append(ids, id.(string))
+		idStr := id.(string)
+		if isReadOnlyRole && !model.CheckBlockIdAccessableByPublishAccess(c, publishAccess, idStr) {
+			continue
+		}
+		ids = append(ids, idStr)
+	}
+	if isReadOnlyRole && 0 < len(idsArg) && len(ids) == 0 {
+		ret.Data = []*model.BlockInfo{}
+		return
+	}

This multi-layered approach ensures that single-object lookup, document-level metadata queries, and bulk block retrieval operations are systematically validated against the user's privilege scope before any data is processed from the database.

Exploiting CVE-2026-68585 requires network reachability to the target SiYuan API instance and knowledge of a target block identifier. Because block identifiers are typically structured as 22-character alphanumeric values or timestamps (e.g., 20260715120000-abc123z), they are not highly susceptible to blind brute-force attacks. However, an attacker can harvest valid block IDs through public documentation, shared assets, search engine indexes, backlink references, or other public pages exposed by the same instance.

Once a valid candidate ID is identified, the attacker crafts a POST request to the /api/block/getBlockInfo endpoint. The body of the request contains the targeted block ID inside a JSON payload:

{
  "id": "20260715120000-abc123z"
}

An unauthenticated or read-only client can dispatch this payload using simple CLI tools such as curl:

curl -X POST -H "Content-Type: application/json" \
     -d '{"id": "20260715120000-abc123z"}' \
     https://notes.example.com/api/block/getBlockInfo

On vulnerable installations, the server processes the database query and responds with structural details of the block. This response includes critical metadata such as the containing notebook name, the raw filesystem path on the host, the root document title, and any associated custom icons. This allows the attacker to reconstruct the folder structure and discover the existence and names of highly confidential records.

The process of the exploitation flow is illustrated in the diagram below:

The impact of this vulnerability is primarily classified under unauthorized information disclosure. While it does not permit arbitrary code execution or direct file modification, it compromises the confidentiality of metadata across the entire SiYuan database. Attackers can verify the existence of private documents, discover administrative directory structures, and read the titles of restricted files.

For organization-wide knowledge bases or personal repositories containing sensitive intellectual property, leaking the existence and titles of restricted files (e.g., "Project_Alpha_Acquisition_Strategy.sy") can lead to significant strategic damage. The leaked path variables also disclose host-level directory structures, providing reconnaissance data that can be combined with other system vulnerabilities to escalate privileges.

The CVSS v3.1 base score is established at 5.8 (Medium), with a vector string of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N. The scope metric is set to "Changed" because the protection boundary of the published-to-web subset is bypassed to read the state of independent, private documents. The EPSS score remains low at approximately 0.00194, indicating a limited likelihood of automated, widespread exploit campaigns, but the vulnerability presents an active threat to targeted, public-facing instances.

To remediate CVE-2026-68585, administrators must upgrade their SiYuan installations to version v3.7.3 or later. This version incorporates the authorization patches that block metadata exposure on restricted endpoints.

If immediate upgrading is not feasible, administrators should deploy mitigation strategies to reduce the attack surface. One effective temporary workaround is to completely disable the public web publish feature, effectively converting the instance into a private, authenticated-only platform. Alternatively, reverse proxies can be configured to block access to the affected endpoints (/api/block/getBlockInfo, /api/block/getDocInfo, /api/block/getDocsInfo) for untrusted source IP ranges.

An evaluation of the fix implemented in commit ffde3b21eca49ae98828747ca126581a553cce8b indicates that the solution is highly complete and structurally sound. By implementing the validation logic at the entry points of the individual query handlers and incorporating a batch-filtering routine inside getDocsInfo, the maintainers have addressed both single-object and multi-object variants of the BOLA vulnerability. No apparent bypasses exist in the patched code paths because the checkBlockInfoPublishAccess helper is bound directly to the read-only session evaluation context, ensuring all restricted queries are validated.