CVE-2026-72808: Unauthorized PDF Annotation Access in SiYuan Knowledge Management System

The SiYuan knowledge management system supports local and published notebook configurations. Users can upload assets, including PDF documents, and annotate them using built-in annotation features. These annotations are stored as separate .sya files. The system implements access-control policies on the root notebook assets, ensuring that unauthorized readers cannot retrieve them if the notebook is private or password-protected.

The vulnerability resides within the /api/asset/getFileAnnotation HTTP API endpoint, which is mapped inside the kernel codebase of SiYuan. This endpoint is exposed to facilitate the retrieval of annotation metadata for a specific document path. However, in vulnerable versions of the application, the endpoint only relies on generic application authentication filters rather than validating granular object-level access controls.

Consequently, an unauthenticated user (if publishing is configured without global authentication) or a read-only viewer can target this API endpoint directly. If the attacker has knowledge of or is able to guess the storage path of a private PDF document, they can fetch its annotations. This bypasses the access controls established for the underlying PDF asset.

The root cause of CVE-2026-72808 is a missing authorization check (CWE-862) inside the file annotation retrieval mechanism. When a request is dispatched to /api/asset/getFileAnnotation, the routing layer verifies general identity context through CheckAuth or basic middleware. Once authenticated, the execution path transfers control directly to the handler function getFileAnnotation inside kernel/api/asset.go.

Within the vulnerable implementation, the input path string is processed to locate the targeted asset file using the helper utility resolveFileAnnotationAbsPath. This function strips the .sya extension, resolves the logical path within the respective storage box, and appends the suffix back to identify the target filesystem location. The handler then checks for file existence and immediately returns the file's binary content to the client.

This design fails to perform any verification against the publish access rules associated with the primary PDF document. While access to the PDF itself via /assets/* routes is blocked by the application's core access control matrix, the annotation endpoint treats the requested resource as an isolated path. Because of this logical separation, the server serves the document's annotations without assessing if the client is permitted to view the underlying parent file.

The vulnerability patch was applied in commit 509b35055940856ec1c89cb4888723c4660b776a. The core architectural change introduces multi-value returns in the path resolution handler to isolate both the asset path and the annotation path, enabling object-level authorization checking prior to file access.

// Patched Path Resolution Function in kernel/api/asset.go
func resolveFileAnnotationAbsPath(assetRelPath string) (annotationAbsPath, assetAbsPath string, err error) {
	// The .sya is at the end of the URL, e.g., assets/a.pdf?box=<id>.sya
	filePath := strings.TrimSuffix(assetRelPath, ".sya")
	assetAbsPath, err = model.GetAssetAbsPathInBox(filePath, "")
	if err != nil {
		return
	}
	annotationAbsPath = assetAbsPath + ".sya"
	return
}

In getFileAnnotation, the updated handler evaluates whether the requester is operating under a restricted read-only role using model.IsReadOnlyRoleContext(c). If this condition evaluates to true, the program retrieves the current publish configurations and issues a specific access-check function:

if model.IsReadOnlyRoleContext(c) {
	publishAccess := model.GetPublishAccess()
	if !model.CheckAbsPathAccessableByPublishAccess(c, assetAbsPath, publishAccess) {
		ret.Code = http.StatusForbidden
		ret.Msg = http.StatusText(http.StatusForbidden)
		return
	}
}

This logic enforces that unauthenticated or guest sessions must have explicit publish permissions to the parent asset file. If the access check fails, the handler halts execution and returns an HTTP 403 Forbidden status. This prevents the server from proceeding to the file-reading stage, remediating the direct access vector.

An attacker seeking to exploit CVE-2026-72808 must satisfy specific environment and knowledge prerequisites. The target SiYuan deployment must have active public network access or publish capabilities enabled. Furthermore, the targeted resource must reside inside a non-encrypted storage block, as the vulnerability does not allow bypassing encryption boundaries.

The primary barrier to successful exploitation is acquiring the logical asset path of the target document. Because asset filenames are typically randomized or generated programmatically during insertion, brute-forcing is the primary constraint. However, if paths are exposed through other leakage channels, or if guessing is feasible, exploitation can be initiated.

The exploit is conducted by sending an HTTP POST request directly to the API routing endpoint. Below is a conceptual representation of the structure required for an exploit payload:

POST /api/asset/getFileAnnotation HTTP/1.1
Host: target-siyuan-instance:6806
Content-Type: application/json
 
{
  "path": "assets/confidential_document.pdf?box=20261024090123-abc1234.sya"
}

Upon receiving this request, a vulnerable server will process the payload, convert the path via the unpatched helper, bypass authorization checks, and return the .sya data. The returned structure contains cleartext information including highlighted document text, user-written margins, and structural metadata of the document.

The impact of CVE-2026-72808 is restricted to the unauthorized disclosure of information. It does not provide remote code execution, server-side request forgery, or administrative write access to the host server. The integrity and availability of the files remain unaffected.

Despite these limitations, the confidentiality impact can be significant for environments utilizing SiYuan for sensitive document storage. Annotations often contain direct quotes, editorial critiques, or sensitive clarifications of private legal, financial, or personal documents. The exposure of these comments effectively compromises the confidentiality boundary of the host notebook.

The vulnerability has been evaluated with a CVSS v4.0 base score of 6.9, emphasizing that the attack can be launched over the network with low complexity and no user interaction. The EPSS score is currently low, indicating that widespread automated exploitation is unlikely due to the requirement of knowing the asset paths beforehand.

Detection of exploit attempts requires reviewing proxy and application access logs. Administrators should analyze incoming traffic for unexpected POST requests directed at /api/asset/getFileAnnotation. High frequencies of these requests from unauthenticated or read-only source IP addresses represent potential path-guessing or scanning activity.

The recommended remediation is to upgrade the SiYuan application deployment to version 3.7.4 or later. This introduces the authorization check in the API handler.

If immediate patching is not possible, defensive mitigations can be applied at the network or reverse proxy layer. Administrators can write rules in Nginx, Cloudflare, or local web application firewalls (WAF) to block requests to /api/asset/getFileAnnotation originating from untrusted networks:

# Nginx block to restrict the file annotation endpoint
location /api/asset/getFileAnnotation {
    allow 127.0.0.1;
    allow 192.168.1.0/24;
    deny all;
}

Additionally, organizations should avoid storing highly confidential information in unencrypted notebooks. Utilizing SiYuan's native encrypted box feature ensures that data remains protected even if direct filesystem-level retrieval vulnerabilities are discovered.