CVE-2026-74904 in SiYuan
Summary
by MITRE • 08/18/2026
SiYuan before v3.7.4 is missing authorization checks in 17 block metadata/content endpoints in kernel/api/block.go (including getRefText, checkBlockExist, and getBlockBreadcrumb). These handlers are gated only by basic authentication (model.CheckAuth) and lack publish-access filtering, allowing anonymous publish-mode readers to disclose private block content-derived text, structural metadata, and existence information for arbitrary block IDs across the workspace.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in SiYuan versions prior to 3.7.4 represents a critical authorization bypass within the application's core API layer, specifically located in the kernel/api/block.go module. This flaw affects seventeen distinct endpoints responsible for handling block metadata and content retrieval operations. Among these affected handlers are getRefText, checkBlockExist, and getBlockBreadcrumb, which serve fundamental functions such as resolving text references from other blocks, verifying the existence of specific data structures within the workspace database, and retrieving navigation breadcrumbs that describe a block's hierarchical position. The root cause of this vulnerability lies in an insufficient access control mechanism where these sensitive operations are gated solely by basic authentication via model.CheckAuth rather than implementing granular permission checks based on publish-mode visibility settings. This architectural oversight allows any user with valid credentials to execute requests against these endpoints without the system verifying whether the target block is intended for public consumption or restricted private use, thereby creating a significant security gap in data isolation logic.
From an operational perspective, this authorization flaw enables authenticated users who are designated as anonymous publish-mode readers to access sensitive information that should remain confidential within their own workspace context. By exploiting these endpoints, an attacker can disclose the actual text content of blocks, retrieve structural metadata such as block IDs and parent-child relationships, and confirm the existence of arbitrary block identifiers across the entire workspace. This capability effectively allows for unauthorized data exfiltration where private notes, documents, or configuration details intended only for specific users are exposed to anyone with a valid account on the instance. The ability to check block existence also facilitates reconnaissance activities, allowing attackers to map out the internal structure and content organization of a target workspace without needing direct access to those sections through the standard user interface. This level of information disclosure can lead to further exploitation scenarios where knowledge of specific block IDs or structural hierarchies is used to craft more targeted attacks against other parts of the application that may have weaker validation logic.
The security implications align closely with CWE-269, which classifies this issue as an Improper Privilege Escalation due to insufficient authorization checks on API endpoints. Furthermore, the exploitation technique maps directly to ATT&CK T1083, specifically the File and Directory Discovery subtechnique, as attackers can enumerate available data structures and content through systematic querying of block metadata. The lack of publish-access filtering means that the application fails to enforce the principle of least privilege for read operations in public-facing modes, treating all authenticated users equally regardless of their intended role or access level relative to specific resources. This violates fundamental web security standards regarding resource-level authorization where access decisions must be made dynamically based on both user identity and resource sensitivity rather than relying solely on session validity.
To mitigate this vulnerability, immediate patching to version 3.7.4 or later is required as it addresses the missing checks in the affected handlers. In environments where upgrading is not immediately feasible, administrators should implement a reverse proxy rule that restricts access to the kernel/api/block.go endpoints for users who are not authorized to view published content. Additionally, application-level fixes must ensure that all block retrieval operations verify publish-mode permissions before returning data or metadata. This involves integrating checks that confirm whether the requesting user has explicit permission to read the specific block ID being queried, rather than relying on general authentication status. Regular security audits of API endpoints should be conducted to identify similar patterns where basic authentication is used as a substitute for granular authorization controls, ensuring that all resource access adheres strictly to defined role-based or attribute-based access policies.