CVE-2026-72808 in SiYuan
Summary
by MITRE • 08/12/2026
SiYuan versions up to and including v3.7.2 (fixed in v3.7.4) contain an information disclosure vulnerability in the /api/asset/getFileAnnotation endpoint, which returns .sya PDF-annotation file content without a publish-access check. Because the endpoint is gated only by CheckAuth (unlike the /assets/* route, which enforces publish access and password), an anonymous reader (when publish authentication is disabled) or any publish RoleReader who knows an asset path can read the private PDF annotations (highlights and notes) of publish-forbidden, password-protected, or unpublished documents. The issue is limited to non-encrypted notebooks; encrypted-box annotations are not exposed.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability identified in SiYuan versions up to and including v3.7.2 represents a critical information disclosure flaw that undermines the security model of the document annotation system. This weakness exists within the /api/asset/getFileAnnotation endpoint which is designed to provide access to PDF annotation files with the .sya extension. The core technical issue stems from insufficient access control validation where the endpoint relies solely on the CheckAuth function rather than implementing the more robust publish access controls that govern other asset routes such as /assets/*. This architectural inconsistency creates a dangerous gap in the security framework where unauthorized parties can bypass normal access restrictions to obtain sensitive annotation data.
The operational impact of this vulnerability is significant for users who rely on SiYuan for document management and collaboration. When publish authentication is disabled, any anonymous user can potentially access private PDF annotations simply by knowing the asset path. Even when publish authentication is enabled, RoleReader users who possess knowledge of specific asset paths can exploit this flaw to read highlights and notes from documents that are otherwise protected. The vulnerability specifically targets documents that are either publish-forbidden, password-protected, or unpublished, creating a scenario where private intellectual property and sensitive annotations become accessible to unauthorized parties. This exposure directly violates the fundamental principle of access control and data confidentiality that security-conscious organizations depend upon.
The technical flaw manifests as a missing authorization check in the getFileAnnotation endpoint implementation, which should enforce the same publish access controls as other asset routes but fails to do so. This inconsistency creates an attack surface where malicious actors can enumerate or guess asset paths and gain access to annotation data without proper authentication. The vulnerability is particularly concerning because it affects non-encrypted notebooks while encrypted-box annotations remain protected, suggesting that the issue lies specifically in the access control logic rather than encryption mechanisms themselves. This selective exposure pattern indicates that the developers may have implemented different security controls for different data types within the same application framework.
Security professionals should note this vulnerability aligns with CWE-284 (Improper Access Control) and represents a classic example of insufficient authorization checks in web applications. The flaw operates under ATT&CK technique T1566 (Phishing) and T1071.004 (Application Layer Protocol: DNS) when attackers use path enumeration techniques to discover valid asset paths, though the primary vector is direct API access. Organizations using SiYuan should immediately implement mitigations including upgrading to version 3.7.4 or later, implementing additional access controls at the network level, and conducting thorough audits of asset access patterns. The recommended remediation involves ensuring all file annotation endpoints enforce the same publish access checks as other asset routes, thereby establishing consistent security boundaries across the application's API surface.
The vulnerability demonstrates how seemingly minor inconsistencies in access control implementation can create significant security risks in document management systems. The lack of proper authorization enforcement in a single endpoint creates a potential data breach scenario where private annotations from sensitive documents become publicly accessible. This flaw underscores the importance of maintaining consistent security controls throughout application frameworks and highlights the need for comprehensive testing of access control mechanisms across all API endpoints. Organizations should implement monitoring solutions to detect unauthorized access attempts to annotation files and establish proper incident response procedures for potential exposure events. The fix in version 3.7.4 addresses this by implementing proper publish access validation for the getFileAnnotation endpoint, ensuring that annotation data can only be accessed when appropriate authorization is granted.
This vulnerability serves as a reminder of the critical importance of consistent security implementation across all application components. The inconsistency between the CheckAuth function and the more robust publish access controls creates a dangerous gap where users with minimal privileges can gain access to sensitive information. The fact that encrypted notebooks remain protected while non-encrypted ones are vulnerable suggests that proper encryption mechanisms exist but are not consistently applied to annotation data access control. This pattern indicates that while the core encryption infrastructure functions correctly, the authorization logic for accessing annotation data needs reinforcement. Security teams should consider implementing additional monitoring for annotation file access patterns and establish automated alerts for unusual access attempts to private documents.