Summary
A SQL injection flaw in SiYuan's /api/filetree/searchDocs endpoint allows attacker-controlled input in the keyword parameter to be concatenated directly into SQL without proper escaping or parameterization.
When publish mode is enabled or a RoleReader token is exposed, an attacker can issue stacked queries against a read-write SQLite database, potentially reading and modifying cleartext notebook content across the instance.
Affected context
The vulnerability occurs in SiYuan deployments that expose the /api/filetree/searchDocs endpoint, either through publish mode or RoleReader tokens.
It is relevant when the underlying database uses a read-write SQLite handle and the driver permits stacked SQL statements.
In such configurations, untrusted keyword values are concatenated directly into SQL queries used to search document metadata across cleartext notebooks.
Exploit preconditions
- Attack surface: HTTP API endpoint
/api/filetree/searchDocs - Required access:
- A valid publish RoleReader token, or
- Unauthenticated access when publish mode is enabled with
Publish.Auth.Enable = false - Trigger point: Supplying crafted
keywordinput that becomes part of the SQL query string - Why exploitation is possible: The application builds SQL by string concatenation without parameter binding or escaping, and the SQLite driver executes stacked statements on a read-write connection
Why this happens
This issue is a classic example of CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection').
The searchDocs logic dynamically constructs SQL using caller-supplied keyword values, directly embedding them into the query string.
Without parameterized queries or robust input neutralization, special characters such as quotes and semicolons are interpreted as part of the SQL syntax rather than data.
Because the database connection is read-write and the driver supports multiple semicolon-separated statements, injected input can alter the intended query or append additional commands, enabling arbitrary reads and writes across cleartext notebook tables.
Potential impact
- An attacker may read sensitive content from all non-encrypted notebooks.
- An attacker could modify, corrupt, or delete notebook entries and metadata.
- An attacker can create or alter application-level data to impersonate users or forge content.
- An attacker may introduce malicious records that affect downstream processing or exports.
- An attacker could impact availability by performing destructive operations against the database.
General mitigation guidance
Mitigation typically focuses on eliminating direct string concatenation of untrusted input into SQL statements.
Secure patterns include:
- Using parameterized queries or prepared statements for all database access paths that consume user or token-derived input.
- Applying strict server-side validation and normalization of search parameters, treating them as data only and constraining allowable characters.
- Structuring the data access layer so that query construction is centralized and follows a consistent, safe API that disallows ad hoc SQL assembly.
- Restricting database permissions to the minimum necessary for the application's operations, reducing the blast radius of any injected statements.
- Considering separation of search functionality into a read-only context where write operations are technically impossible, even if injection occurs.
How teams detect issues like this
Detection often combines static and review-based approaches:
- Static analysis rules that flag SQL construction via string concatenation, especially where input parameters flow directly into query strings.
- Code review practices that require developers to justify any dynamic SQL and demonstrate the use of parameter binding instead of manual escaping.
- Centralized logging of database errors and anomalous query patterns, such as unexpected semicolons, comment markers, or suspicious predicates.
- Security tests and fuzzing of API endpoints with crafted input designed to reveal injection paths and stacked statement execution behavior.
- Integration of automated security scanning tools in CI pipelines that recognize common SQL injection sinks and tainted data flows.
