CVE-2026-72799: Missing Authorization in SiYuan Filetree Path-Resolution API

SiYuan is a local-first personal knowledge management system developed in Go and TypeScript. It supports a publish mode, allowing users to share specific notebooks and documents with the public or with authenticated readers. To protect sensitive information, users can restrict pages by setting their status to hidden, password-protected, or fully disabled for publication.

The core file-management backend, implemented as a Go service running on the Gin HTTP framework, is responsible for processing document hierarchies and serving filetrees. When publish mode is enabled without password authentication, the application exposes API endpoints intended to assist the frontend in resolving filetree paths. These endpoints resolve internal document identifiers (IDs) into human-readable hierarchical paths and vice versa.

In versions prior to v3.7.4, the application fails to validate whether the requested resources are authorized for the calling context. Because of this omission, any unauthenticated network actor can query these endpoints directly. The lack of authorization checks exposes metadata representing the entire structure of the personal knowledge base, including documents explicitly marked as private.

The root cause of CVE-2026-72799 lies in a missing authorization check within the handlers defined in kernel/api/filetree.go. When an API request is received, the handler processes the incoming payload and queries the database or memory-mapped index (BlockTree) without verifying the client's current authorization level against the target resource's publication properties. The application assumes that any client allowed to access the basic read-only context is also allowed to resolve paths for all existing IDs.

Specifically, the affected endpoints include /api/filetree/getFullHPathByID, /api/filetree/getHPathByID, /api/filetree/getPathByID, /api/filetree/getIDsByHPath, and /api/filetree/getHPathByPath. These endpoints perform direct lookups in the internal SQLite database or the structured Go models. These lookups are performed without filtering results based on whether the containing notebook or the individual document is flagged as hidden, password-protected, or forbidden from being published.

This behavior allows unauthorized users to perform targeted queries. An attacker with access to a single valid ID or human-readable path can traverse the entire parent and child relationships of that node. Because document IDs are generated using predictable timestamp patterns, attackers can brute-force the ID space or sequentially resolve metadata to extract the exact logical structure of folders and files.

To resolve the vulnerability, the developers introduced strict role context and publish-access validation checks inside the kernel/api/filetree.go handler methods. The fix utilizes the model.IsReadOnlyRoleContext(c) helper function to detect whether the current HTTP request originates from an unauthenticated or read-only reader session. If a read-only context is active, the application fetches the active publication configuration using model.GetPublishAccess() and enforces permissions.

// Code snippet showing the added validation in getHPathByID
if model.IsReadOnlyRoleContext(c) {
	publishAccess := model.GetPublishAccess()
	if !model.CheckBlockIdMetadataAccessableByPublishAccess(c, publishAccess, id) {
		ret.Code = -1
		ret.Msg = model.ErrTreeNotFound.Error()
		return
	}
}

The check calls CheckBlockIdMetadataAccessableByPublishAccess, which maps to the underlying database and checks if the path or box ID is marked as disabled or password-protected. If the validation fails, the API responds with a generic error message indicating that the tree or block was not found, preventing metadata leakage.

// The array filter implementation introduced to protect bulk path resolutions
func filterFileTreePathsByPublishMetadataAccess(c *gin.Context, paths []string) (ret []string) {
	if !model.IsReadOnlyRoleContext(c) {
		return paths
	}
	ids := make([]string, 0, len(paths))
	for _, p := range paths {
		ids = append(ids, util.GetTreeID(p))
	}
	blockTrees := treenode.GetBlockTrees(ids)
	publishAccess := model.GetPublishAccess()
	ret = make([]string, 0, len(paths))
	for i, p := range paths {
		if model.CheckBlockTreeMetadataAccessableByPublishAccess(c, publishAccess, blockTrees[ids[i]]) {
			ret = append(ret, p)
		}
	}
	return
}

This filter resolves the IDs from each path, loads the cached BlockTree records, and evaluates access permissions on each item individually. For documents that are password-protected, the verification routine CheckBlockTreeMetadataAccessableByPublishAccess ensures that the client possesses the correct authorization cookie value via CheckPublishAuthCookie before returning the metadata.

Exploitation of CVE-2026-72799 is straightforward and requires no active user interaction or elevated privileges. An attacker only needs network-level access to the target SiYuan instance when it is configured in publish mode with public access allowed. By sending a crafted HTTP POST request containing a known or predicted document ID, the attacker can verify the existence and retrieve the hierarchical path of the document.

The attack begins with reconnaissance to find exposed SiYuan instances. Once identified, the attacker targets the /api/filetree/getFullHPathByID endpoint with structural or guessable document IDs, which are typically formatted with a prefix based on the creation timestamp. If the server is vulnerable, it responds with the full structural path containing sensitive directory names and private file titles.

To discover all files within a private directory, the attacker can leverage the /api/filetree/getIDsByHPath endpoint. By specifying a known or leaked path prefix, the API returns a complete array of document IDs under that directory. The attacker can then programmatically iterate through these retrieved IDs to reconstruct the entire document hierarchy of the host system.

The vulnerability carries a CVSS v4.0 base score of 6.9 and a CVSS v3.1 base score of 5.8, reflecting its impact on confidentiality. Although the vulnerability does not allow direct remote code execution or modification of data, the leakage of document metadata represents a significant privacy and security risk. This is particularly critical because personal knowledge bases often contain sensitive personal, corporate, or financial details.

An attacker exploiting this flaw can map the entire logical layout of private notebooks, revealing restricted project directories, client lists, internal system designs, or credential archives. Knowledge of document titles and their paths can also expose security-sensitive terms that are meant to be kept hidden, such as directories labeled with internal server names, proprietary codebases, or key management folders.

Furthermore, this metadata leakage undermines the efficacy of document password protections. While an attacker cannot directly read the raw markdown contents of a password-protected document through these endpoints, learning the precise document titles and directory locations provides valuable targets for secondary attacks. These secondary attacks include credential stuffing or spear-phishing campaigns tailored to the revealed hierarchy.

The most effective remediation is upgrading all SiYuan instances to version v3.7.4 or higher, which properly implements server-side authorization validations on all filetree APIs. If upgrading is not immediately feasible, administrators must implement network-level or application-level mitigations to prevent unauthorized access.

Administrators should configure the application to enable publish authentication by setting Publish.Auth.Enable to true. This action enforces password verification before allowing any access to the endpoints. Additionally, implementing a reverse proxy such as Nginx or Caddy is highly recommended to block external access to the /api/filetree/* endpoints from untrusted networks.

> [!NOTE] > Restricting API access via a reverse proxy may impact some frontend editing and navigation functionalities for legitimate remote users, but it serves as an effective temporary mitigation until the software can be patched.

To detect exploitation attempts, security operations teams should analyze reverse proxy or web server access logs. They should search for sequential POST requests to /api/filetree/getFullHPathByID or similar endpoints originating from unexpected IP addresses, which typically indicate automated mapping and enumeration scripts.