CVE-2026-69084: SiYuan before v3.7.3 SQL Injection via searchEmbedBlock

CVE: This vulnerability corresponds to CVE-2026-69084.

Summary

The /api/search/searchEmbedBlock endpoint passes a client-supplied SQL statement verbatim to the database with no validation. 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 statement runs on the main read-write siyuan.db handle through a driver that executes stacked statements, with no single-statement or read-only guard. An unauthenticated request can therefore execute arbitrary SQL reading and writing content across all cleartext notebooks.

Unlike SQL injection into a fixed query, this endpoint accepts a full SQL statement by design and simply fails to restrict who may call it or what the statement may do.

Details

Data flow verbatim, unvalidated:

- searchEmbedBlock (kernel/api/search.go): stmt := arg["stmt"].(string) passed directly to model.SearchEmbedBlock(stmt, …). No validation. - SearchEmbedBlock → SearchEmbedBlockInBox → sql.SelectBlocksRawStmtNoParse(stmt, …) → selectBlocksRawStmt → query(stmt). - query() (kernel/sql/database.go) calls db.Query(stmt) on the global siyuan.db handle.

Missing guards. The comparable endpoints enforce restrictions this one omits: - /api/query/sql runs CheckSingleStatement (all modes) and CheckReadonlyStatement (readonly mode) and is route-gated CheckAuth + CheckAdminRole + CheckReadonly. - fullTextSearchBlock rejects the SQL search method for non-admins (if method == 2 && !IsAdminRoleContext(c)).

searchEmbedBlock has none of these, no statement check, no read-only check, no admin gate.

Route/auth tier. router.go: Handle("POST", "/api/search/searchEmbedBlock", model.CheckAuth, searchEmbedBlock), CheckAuth only. CheckAuth admits RoleReader, and the publish proxy forwards port-6808 traffic with a Reader JWT (anonymous account when publish auth is disabled). Anonymous/reader reachable.

Handle/stacking. query() uses the global siyuan.db handle, the same read-write handle behind the accepted searchDocs finding. Driver is the vendored 88250/go-sqlite3 (mattn fork), whose connection query loops over ;-separated statements, so stacked statements execute for their side effects. The DSN sets no mode=ro / queryonly, so the handle is read-write; ATTACH is available.

Post-hoc filter does not bound the statement. FilterEmbedBlocksByPublishAccess runs on the returned slice after query() has executed. It filters rows; it cannot constrain what the statement did. Any write or ATTACH side effect has already occurred before the filter runs. It is not a security boundary for this sink.

Scope. The main blocks/DB handle spans every opened cleartext notebook. Encrypted notebooks use separate per-box databases and are excluded.

Impact

An unauthenticated request (publish mode with auth disabled) or any publish RoleReader executes arbitrary SQL on the main read-write database. This permits cross-notebook read disclosure of document content, and via the read-write handle and statement stacking, modification of database content and ATTACH-reachable files. No admin role, CSRF token, or write permission through the normal API is required. Encrypted notebooks are not exposed. Code execution is not reachable in the default build (no loadextension).

PoC Steps

1. Build the kernel image from pinned HEAD

docker build -f D:/bb/zitadel/chatto/siyuan/Dockerfile.poc -t siyuan-head D:/bb/zitadel/chatto/siyuan

2. Run fresh, workspace mounted to the host

docker rm -f siyuan-poc 2>nul docker run -d --name siyuan-poc -p 6806:6806 -p 6808:6808 -v D:/bb/siyuan:/siyuan/workspace siyuan-head serve --accessAuthCode=1234567 --port=6806

Confirm it booted (version string back, not Cobra help):

docker logs siyuan-poc curl -s http://127.0.0.1:6806/api/system/version

3. Grab the admin API token from the host file. Use that value wherever TOKEN appears below (yours was g4wj3r04ntobe9m4).

4. Turn on the reader surface: publish on 6808, Basic Auth OFF

curl -s -X POST http://127.0.0.1:6806/api/setting/setPublish -H "Content-Type: application/json" -H "Authorization: Token TOKEN" -d "{\"enable\":true,\"port\":6808,\"auth\":{\"enable\":false,\"accounts\":[]}}"

Must return "data":{"port":6808,...} (non-zero port = bound OK). Port 6808, not 6806.

5. THE PROOF: anonymous reader on 6808, no token (the differential)

Guarded sibling rejects reader SQL: curl -i -X POST http://127.0.0.1:6808/api/search/fullTextSearchBlock -H "Content-Type: application/json" -d "{\"query\":\"SELECT FROM blocks LIMIT 1\",\"method\":2}"

→ -1 / "SQL search requires administrator privileges"

searchEmbedBlock accepts the same reader SQL (no guard): curl -i -X POST http://127.0.0.1:6808/api/search/searchEmbedBlock -H "Content-Type: application/json" -d "{\"embedBlockID\":\"\",\"stmt\":\"SELECT FROM blocks LIMIT 1\",\"excludeIDs\":[]}" → HTTP 200 / code:0 : arbitrary SQL executed at the anonymous reader tier. This pair is the finding.

Suggested fix

Apply the same controls the sibling SQL endpoints already use: route searchEmbedBlock through CheckSingleStatement and CheckReadonlyStatement, and gate the raw-SQL capability behind CheckAdminRole (as /api/query/sql and fullTextSearchBlock's SQL method do). At minimum, the read paths should run on a queryonly=1 handle so a reader-reachable statement cannot write or ATTACH.