CVE-2026-69085

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.

Summary

The /api/filetree/searchDocs endpoint concatenates the caller-supplied search keyword directly into a SQL statement with no escaping and no parameter binding. The endpoint is gated by CheckAuth only reachable by the publish RoleReader token, and by the anonymous account when Publish.Auth.Enable is false. The resulting statement runs on a read-write SQLite handle through a driver that executes stacked (;-separated) statements, against the global blocks table spanning all cleartext notebooks. An unauthenticated request can therefore read and write database content across every non-encrypted notebook on the instance.

Details

Data flow, unescaped and unbound at every hop:

• searchDocs (kernel/api/filetree.go): k := arg["k"].(string) passed straight to model.SearchDocs(k, …), no sanitization.
• SearchDocs (kernel/model/file.go): after TrimSpace and strings.Fields, each token is spliced into a single-quoted LIKE literal by concatenation condition.WriteString("(hpath LIKE '%" + k + "%'"). No escaping, no '' doubling, no bind placeholder.
• NAMFilter (kernel/conf/search.go): appends " OR name LIKE '%" + keyword + "%'" (and alias, memo) the same way, enabled by default.
• QueryRootBlockByCondition (kernel/sql/block_query.go): "SELECT *, … FROM blocks WHERE type = 'd' AND " + condition + " ORDER BY … LIMIT …" passed to query(sqlStmt).

The only value-inspecting guard is ast.IsNodeIDPattern(keyword), which merely routes an exact-ID-shaped keyword to a different branch; a normal keyword falls through to the concatenation. strings.Fields prevents literal whitespace within a token this constrains payload construction but is not sanitization or confinement.

Driver / statement stacking. The driver is the vendored github.com/88250/go-sqlite3 (mattn fork), registered as sqlite3_extended. query() calls db.Query, and the driver's connection query implementation loops over ;-separated statements preparing and executing each in turn so a stacked statement executes for its side effects. SiYuan's CheckSingleStatement / CheckReadonlyStatement guards exist but are wired only into the explicit SQL endpoints (api/sql.go, cli, mcp); the searchDocs > query() path does not call them.

Handle. The DSN (kernel/model/database.go) sets _journal_mode=WAL&_synchronous=OFF&… with no mode=ro and no _query_only. It is the same read-write handle used for indexing Exec calls, so stacked INSERT/UPDATE/DELETE execute, and ATTACH is available. load_extension is not enabled in this build (no build tag / ConnectHook enabling it), so the ceiling is database read/write, not code execution.

Scope. The blocks table indexes every opened non-encrypted notebook. Encrypted notebooks use separate per-box databases and are excluded. Scope is therefore all cleartext notebook content on the instance cross-notebook, not publish-scoped.

Impact

An unauthenticated request (publish mode with auth disabled) or any publish RoleReader reaches an unescaped, unparameterized SQL concatenation on a read-write handle whose driver executes stacked statements, against a table spanning all cleartext notebooks. This permits cross-notebook disclosure of document content and, via statement stacking on the read-write handle, modification of database content (and ATTACH-reachable files). No admin role, no CSRF token, no write permission through the normal API is required; the publish surface alone is sufficient. Encrypted notebooks are not exposed. Code execution is not reachable in the default build (no load_extension).

Root cause

The keyword is split on whitespace and each token is spliced into a LIKE literal without escaping or binding:

• SearchDocs builds each condition as (hpath LIKE '%<token>%' ...) (file.go:199).
• NAMFilter appends OR name LIKE '%<token>%', alias, memo the same way (search.go:135-142). -…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-33jq-p8c2-q3q4. This link is maintained to preserve external references.

Original Description

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.CVE-2026-69085

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.

Summary

The /api/filetree/searchDocs endpoint concatenates the caller-supplied search keyword directly into a SQL statement with no escaping and no parameter binding. The endpoint is gated by CheckAuth only reachable by the publish RoleReader token, and by the anonymous account when Publish.Auth.Enable is false. The resulting statement runs on a read-write SQLite handle through a driver that executes stacked (;-separated) statements, against the global blocks table spanning all cleartext notebooks. An unauthenticated request can therefore read and write database content across every non-encrypted notebook on the instance.

Details

Data flow, unescaped and unbound at every hop:

• searchDocs (kernel/api/filetree.go): k := arg["k"].(string) passed straight to model.SearchDocs(k, …), no sanitization.
• SearchDocs (kernel/model/file.go): after TrimSpace and strings.Fields, each token is spliced into a single-quoted LIKE literal by concatenation condition.WriteString("(hpath LIKE '%" + k + "%'"). No escaping, no '' doubling, no bind placeholder.
• NAMFilter (kernel/conf/search.go): appends " OR name LIKE '%" + keyword + "%'" (and alias, memo) the same way, enabled by default.
• QueryRootBlockByCondition (kernel/sql/block_query.go): "SELECT *, … FROM blocks WHERE type = 'd' AND " + condition + " ORDER BY … LIMIT …" passed to query(sqlStmt).

The only value-inspecting guard is ast.IsNodeIDPattern(keyword), which merely routes an exact-ID-shaped keyword to a different branch; a normal keyword falls through to the concatenation. strings.Fields prevents literal whitespace within a token this constrains payload construction but is not sanitization or confinement.

Driver / statement stacking. The driver is the vendored github.com/88250/go-sqlite3 (mattn fork), registered as sqlite3_extended. query() calls db.Query, and the driver's connection query implementation loops over ;-separated statements preparing and executing each in turn so a stacked statement executes for its side effects. SiYuan's CheckSingleStatement / CheckReadonlyStatement guards exist but are wired only into the explicit SQL endpoints (api/sql.go, cli, mcp); the searchDocs > query() path does not call them.

Handle. The DSN (kernel/model/database.go) sets _journal_mode=WAL&_synchronous=OFF&… with no mode=ro and no _query_only. It is the same read-write handle used for indexing Exec calls, so stacked INSERT/UPDATE/DELETE execute, and ATTACH is available. load_extension is not enabled in this build (no build tag / ConnectHook enabling it), so the ceiling is database read/write, not code execution.

Scope. The blocks table indexes every opened non-encrypted notebook. Encrypted notebooks use separate per-box databases and are excluded. Scope is therefore all cleartext notebook content on the instance cross-notebook, not publish-scoped.

Impact

An unauthenticated request (publish mode with auth disabled) or any publish RoleReader reaches an unescaped, unparameterized SQL concatenation on a read-write handle whose driver executes stacked statements, against a table spanning all cleartext notebooks. This permits cross-notebook disclosure of document content and, via statement stacking on the read-write handle, modification of database content (and ATTACH-reachable files). No admin role, no CSRF token, no write permission through the normal API is required; the publish surface alone is sufficient. Encrypted notebooks are not exposed. Code execution is not reachable in the default build (no load_extension).

Root cause

The keyword is split on whitespace and each token is spliced into a LIKE literal without escaping or binding:

• SearchDocs builds each condition as (hpath LIKE '%<token>%' ...) (file.go:199).
• NAMFilter appends OR name LIKE '%<token>%', alias, memo the same way (search.go:135-142). -…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-33jq-p8c2-q3q4. This link is maintained to preserve external references.

Original Description

SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance.CVE-2026-69085

SiYuan: Unauthenticated SQL injection in searchDocs via unescaped keyword (publish mode): cross-notebook read/write with statement stacking in github.com/siyuan-note/siyuan/kernel