Unauthenticated SQL Injection in SiYuan's searchDocs Endpoint Exposes Cross-Notebook Data (CVE-2026-69085)

What happened

A security advisory (GHSA-33jq-p8c2-q3q4) discloses an unauthenticated SQL injection in SiYuan's /api/filetree/searchDocs endpoint, tracked as CVE-2026-69085 with a reported CVSS of 10.0. According to the advisory, the search keyword parameter is concatenated directly into a SQL LIKE condition with no escaping or parameter binding, across multiple code paths (SearchDocs in kernel/model/file.go and NAMFilter in kernel/conf/search.go) before being passed to a query executor in kernel/sql/block_query.go.

The endpoint is reachable with only the publish-mode RoleReader token, or by a fully anonymous caller when Publish.Auth.Enable is set to false. The advisory states the underlying SQLite driver (a vendored fork, github.com/88250/go-sqlite3) executes stacked, semicolon-separated statements, and that the connection used is a read-write handle rather than a read-only one. The query targets the global blocks table, which the advisory says spans all opened, non-encrypted notebooks on an instance — encrypted notebooks use separate per-box databases and are reported as unaffected. A proof-of-concept is included that discloses sqlite_version() through the search response as a read-only demonstration; the advisory notes that code execution is not reachable in the default build because load_extension is not enabled.

Why it matters for defenders

If accurate, this allows an attacker with no valid credentials (in the auth-disabled publish configuration) or with only low-privilege publish reader access to read, and potentially modify via statement stacking, content across every non-encrypted notebook on an affected SiYuan instance — not just the notebook being published. For any organization running SiYuan with its publish/sharing feature enabled, this collapses the intended read-only, scoped-access boundary into full cross-notebook database access. The advisory frames this as applicable to any deployment exposing the publish surface, regardless of whether the admin role or normal API write permissions are otherwise locked down.

What defenders should watch for or do now

• Identify any internet- or network-reachable SiYuan instances with the publish feature enabled, and check whether Publish.Auth.Enable is set to false — the advisory indicates this removes the authentication requirement entirely.
• Review access and application logs for requests to /api/filetree/searchDocs containing SQL metacharacters, UNION/SELECT keywords, or the /**/ comment pattern used in the published PoC to defeat whitespace splitting in the keyword field.
• Treat any unusual or unexpected content appearing in search results — particularly content attributable to a different notebook than the one being queried — as a potential indicator of exploitation.
• Until a patched build is available and applied, consider restricting or disabling the publish feature, or at minimum enforcing Publish.Auth.Enable, as a mitigating control; the advisory's suggested fix is to parameterize the search query and route this code path through SiYuan's existing statement-safety checks.
• This is an application-layer SQL injection issue specific to SiYuan's search implementation — it is not a detection we can validate against a specific SIEM query at this time, so treat the above as hunting guidance rather than a packaged rule.

Developing intel

This write-up is based solely on the GHSA advisory text as published and should be treated as developing intelligence; details such as patch availability and affected version ranges may be refined as the vendor and researchers provide updates. For full technical detail, including the proof-of-concept script, see the original advisory: GHSA-33jq-p8c2-q3q4.