CVE-2026-87808 in SiYuan
Summary
by MITRE • 09/09/2026
SiYuan versions <= 3.8.1 contain an incomplete fix for CVE-2026-32767 (GHSA-j7wh-x834-p3r7). The prior fix (commit d5e2d0bc) added an administrator check for SQL mode (method=2) in POST /api/search/fullTextSearchBlock, but the endpoint still does not enforce the application's read-only boundary: for method=2 it forwards caller-supplied SQL to the blocks database query path without calling model.CheckReadonly or CheckReadonlyStatementInBox. As a result, when a workspace runs in read-only mode (--readonly=true), an authenticated administrator can submit arbitrary SQL through /api/search/fullTextSearchBlock and obtain raw read access to the blocks database, even though the dedicated /api/query/sql endpoint is blocked in that mode. Fixed in v3.8.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
SiYuan versions 3.8.1 and earlier contain a critical security flaw resulting from an incomplete remediation of CVE-2026-32767, which allows authenticated administrators to bypass read-only restrictions and execute arbitrary SQL queries against the underlying database. This vulnerability stems from a logic error in the implementation of access controls for specific API endpoints, specifically within the full-text search functionality. While previous security patches attempted to address this issue by adding an administrator check for SQL mode operations via method=2 on the POST /api/search/fullTextSearchBlock endpoint, the fix was insufficient because it failed to enforce the application's read-only boundary constraints. The core technical flaw lies in the fact that when a workspace is configured with the --readonly=true flag, the system correctly blocks direct access through dedicated SQL query endpoints such as /api/query/sql. However, the full-text search endpoint remains vulnerable because it forwards caller-supplied SQL statements directly to the database query path without invoking essential security checks like model.CheckReadonly or CheckReadonlyStatementInBox. This oversight creates a significant gap in defense-in-depth strategies, allowing an attacker who has obtained administrative credentials to circumvent read-only restrictions and gain raw, unrestricted read access to the blocks database.
The operational impact of this vulnerability is severe for organizations relying on SiYuan's read-only mode for security or compliance purposes. An authenticated administrator can exploit this flaw by crafting specific HTTP POST requests with method=2 parameters that contain arbitrary SQL injection payloads targeting the internal SQLite database structure. Since the application does not validate these inputs against read-only policies, the attacker can extract sensitive data including user notes, metadata, and potentially other workspace content stored in the blocks table. This effectively nullifies the security benefits of running SiYuan in a restricted environment, as the intended isolation between administrative functions and data integrity is broken. The vulnerability aligns with CWE-209, which describes an information exposure through an error message or behavioral artifact, but more accurately maps to CWE-89 for SQL Injection due to improper neutralization of special elements used in an SQL command. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework, this behavior corresponds to T1213 Data from Information Repositories and potentially T1059 Command and Scripting Interpreter if the database engine allows execution of external scripts or commands through specific SQLite configurations.
To mitigate this risk, organizations must immediately upgrade SiYuan to version 3.8.2 or later, where the developers have implemented a complete fix that ensures all SQL mode operations respect the read-only boundary regardless of the endpoint used. Until an upgrade is possible, administrators should restrict network access to the /api/search/fullTextSearchBlock endpoint and ensure that only trusted users with administrative privileges can interact with it, although this is not a robust defense given the nature of the flaw. It is also recommended to audit database logs for any unusual SQL query patterns originating from authenticated sessions if monitoring capabilities are available. The incident highlights the importance of comprehensive regression testing when applying security patches, as partial fixes that address one vector while leaving others open can provide a false sense of security. Developers should ensure that all code paths involving direct database interactions explicitly check and enforce application-level constraints such as read-only modes before executing any user-supplied input against the backend storage system.