CVE-2026-103762 in SiYuan
Summary
by MITRE • 10/02/2026
SiYuan before v3.8.5 contains a missing authorization vulnerability in the getRefCreateSavePath, getShorthandSavePath, and getDocCreateSavePath endpoints that allows read-only publish visitors to learn unpublished notebook box IDs. Attackers with read-only or anonymous publish access can POST any open notebook ID to receive the global save-box ID and save-path template, revealing a hidden notebook's existence and creation time.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in SiYuan versions prior to 3.8.5 represents a critical failure in access control mechanisms within the application’s document management subsystem. Specifically, the flaw resides in three distinct API endpoints: getRefCreateSavePath, getShorthandSavePath, and getDocCreateSavePath. These endpoints are designed to generate file system paths for new documents or references but fail to enforce proper authorization checks against the underlying notebook structure. This architectural oversight allows users with minimal privileges, such as read-only publish visitors or anonymous access tokens, to interact with these functions in a manner that bypasses intended security boundaries. The core technical flaw is an absence of server-side validation ensuring that the requesting user possesses sufficient permissions to view or manipulate the specific notebook ID being queried for path generation purposes.
From a technical perspective, when an attacker submits any open notebook identifier via a POST request to these endpoints, the application processes the input and returns metadata associated with that notebook box. This response includes the global save-box ID and the template used for saving new documents within that context. While this information might appear benign in isolation, it serves as a powerful reconnaissance tool for malicious actors. By successfully retrieving this data, an attacker can confirm the existence of hidden or unpublished notebooks that are not visible through standard browsing interfaces. The returned metadata often contains timestamps related to the creation and modification of these resources, thereby leaking sensitive temporal data about the notebook’s lifecycle.
The operational impact of this vulnerability extends beyond simple information disclosure. It effectively neutralizes the security benefits provided by SiYuan’s publish permissions model. Users who are explicitly granted only read-only access or anonymous visibility into a published workspace can still probe for internal structures that were intended to remain private. This capability allows attackers to map out the entire hierarchy of a target organization’s knowledge base, identifying which notebooks exist even if their contents are not directly accessible. Such enumeration facilitates further attacks by providing precise targets for subsequent exploitation attempts, such as attempting to exploit other vulnerabilities within those specific notebook contexts or conducting social engineering campaigns based on the revealed creation dates and structural relationships between documents.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting a failure in authorization checks that allow lower-privileged users to access resources belonging to higher-privilege domains or private spaces. Furthermore, from an offensive security perspective, this behavior is consistent with ATT&CK technique T1087, Endpoint Discovery, where adversaries gather information about the internal structure of systems and networks. The ability to enumerate hidden entities through API endpoints rather than direct UI interaction also reflects aspects of T1539, Potential Data Exfiltration over Web Service, as sensitive metadata is transmitted out of the secure boundary via standard HTTP requests.
To mitigate this risk, immediate action must be taken by upgrading SiYuan to version 3.8.5 or later, where these authorization checks have been properly implemented. For organizations unable to upgrade immediately due to compatibility constraints, a temporary workaround involves restricting access to the affected API endpoints at the network perimeter using Web Application Firewalls (WAF). Rules should be configured to block POST requests containing notebook identifiers from users who do not possess explicit write or administrative privileges for those specific resources. Additionally, developers should conduct a thorough audit of other similar endpoints within the application to ensure that no analogous authorization gaps exist elsewhere in the codebase. Regular penetration testing focusing on broken access control scenarios is recommended to verify that these mitigations are effective and that no new vectors have been introduced during patching efforts.