Threat database

SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/notebook/getNotebookInfo endpoint that returns notebook metadata without authorization checks. Attackers can read notebook names, document counts, sizes, and timestamps for closed or non-published notebooks that should be hidden from readers.

SiYuan before v3.7.4 fails to properly validate publish access for encrypted notebooks, treating them as publicly accessible by default. Anonymous readers can enumerate and retrieve fully decrypted document content from unlocked encrypted notebooks through the publish API without authentication or key material.

SiYuan versions before v3.7.4 contain an information disclosure vulnerability in the UILayout filter that fails to properly restrict administrator workspace state from publish readers. Unauthenticated attackers can retrieve the administrator's open documents, search terms, notebook paths, and private asset locations by calling the getConf endpoint without authentication.

**CVE:** This vulnerability corresponds to [CVE-2026-69086](https://nvd.nist.gov/vuln/detail/CVE-2026-69086). ### Summary Four attribute-view read endpoints build a filesystem path from a caller-controlled `id`/`avID` and read it without confining the result to the attribute-view storage directory (`DataDir/storage/av/`). On the load (file-exists) code path there is no boundary check, so an `avID` containing `../` segments escapes `storage/av/` and causes the kernel to read a `.json` file elsewhere in the workspace. The endpoints require only `CheckAuth`, which the publish service's `RoleReader` token satisfies; when `Publish.Auth.Enable` is `false` the publish proxy uses the anonymous account, making the surface reachable with no credentials. ### Details Affected endpoints (all gated by `CheckAuth` only, no `CheckAdminRole`): - `POST /api/av/renderAttributeView` &nbsp;→ `arg["id"]` - `POST /api/av/getAttributeViewKeysByID` → `arg["avID"]` - `POST /api/av/getAttributeViewKeys` &nbsp;→ `arg["id"]` - `POST /api/av/getCurrentAttrViewImages` → `arg["id"]` In `model.RenderAttributeView` (`model/attribute_view_render.go`), the only identifier guard `ast.IsNodeIDPattern(avID)` sits **inside** the `if !filelock.IsExist(existPath)` (create) branch: ```go existPath = GetAttributeViewDataPath(avID) // path built from avID, no check if !filelock.IsExist(existPath) { // NOT-EXIST / CREATE branch if !createIfNotExist { return // NotFound } if !ast.IsNodeIDPattern(avID) { // <-- ONLY id guard, create branch only return ErrInvalidID } // ... create ... } attrView, err = av.ParseAttributeView(avID) // LOAD runs unconditionally ``` When the traversal `avID` resolves to a file that already exists, the `!filelock.IsExist(...)` condition is `false`, the entire block (including the line with `ast.IsNodeIDPattern`) is skipped, and control falls straight through to `av.ParseAttributeView(avID)`. That function rebuilds the path via `filepath.Join(DataDir, "storage", "av", avID+".json")` and calls `filelock.ReadFile` with no `filepath.Rel` / `IsSubPath` / `..` rejection: ```go // av.ParseAttributeView -> attributeViewDataPathByBox / GetAttributeViewDataPath avJSONPath = filepath.Join(DataDir, "storage", "av", avID+".json") // no boundary check // -> parseAttributeViewByPathInBox(avJSONPath, boxID) data, _ = filelock.ReadFile(avJSONPath) // SINK ``` `filepath.Join` cleans the path but does **not** reject `..` segments, so it provides no containment. The three `getAttributeView*` endpoints call `ParseAttributeView` with no create branch at all, so they never even reach the `ast.IsNodeIDPattern` check same defect, same auth tier. The root cause is that identifier validation is placed on a single code branch rather than confining the load to the AV base directory, so the load path reads a caller-controlled location. ### PoC **Precondition:** publish mode enabled (default port `6808`); reachable by a `RoleReader` publish token, or anonymously when `Publish.Auth.Enable` is `false`. A request to `/api/av/renderAttributeView` with an `id` composed of `../` path segments that resolves to an existing `.json` file outside `DataDir/storage/av/` causes that file to be read and parsed instead of being rejected, because the identifier validation is only reached on the not-exist/create branch. I have withheld the exact encoded `id` value from this draft to avoid publishing a live traversal against internet-exposed publish instances. I'm happy to provide the precise value and a screenshot privately in this thread on request. ### Impact An authenticated publish `RoleReader` or an anonymous client when publish auth is disabled can cause the kernel to read `.json` files outside the attribute-view directory. Because the loaded file is unmarshalled into the attribute-view structure, the reliable primitives are: 1. Disclosure of attribute-view (database) content from other scopes/notebooks the reader is not authorized to see. 2. A `.json`-path existence oracle for arbitrary workspace locations. Files not conforming to the AV schema are read but reflect little content, and the `.json` suffix is force-appended, so this is **not** a general arbitrary-file read. No admin role, CSRF token, or write permission is required. ### Suggested fix Validate `avID` with `ast.IsNodeIDPattern` before path construction on **all** branches (move it ahead of `FindAttributeViewPath` / `GetAttributeViewDataPath`), or preferably, so every caller inherits it confine at the sink: in `attributeViewDataPathByBox` / `GetAttributeViewDataPath`, compute the joined path and reject it unless `filepath.Rel(avBaseDir, cleaned)` stays within `avBaseDir` (no leading `..`). Sink-side confinement also covers the three `getAttributeView*` endpoints that never reach the create-branch guard.

**CVE:** This vulnerability corresponds to [CVE-2026-69084](https://nvd.nist.gov/vuln/detail/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` / `_query_only`, 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 `load_extension`). ### 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 "{\"embedB

**CVE:** This vulnerability corresponds to [CVE-2026-69083](https://nvd.nist.gov/vuln/detail/CVE-2026-69083). ### Summary The `/api/search/fullTextSearchAssetContent` endpoint exposes two SQL flaws on the asset-content database, both reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`: 1. **method 2** passes a client-supplied SQL statement to the read-write asset-content DB with no single-statement or read-only guard, and without the admin restriction its sibling `fullTextSearchBlock` applies to the same SQL method. 2. **method 3** builds a `REGEXP` clause by concatenating the client expression with no quote-escaping, permitting SQL breakout while the equivalent block-search builder does escape. Both run on a read-write handle through a statement-stacking-capable driver, spanning the cross-notebook asset-content store. ### Details **Route / auth tier.** `router.go`: `Handle("POST", "/api/search/fullTextSearchAssetContent", model.CheckAuth, fullTextSearchAssetContent)`, `CheckAuth` only. Anonymous/reader reachable on the publish surface. `parseSearchAssetContentArgs` reads `method` and `query` straight from the JSON body with no constraint, so both are fully client-controlled. **Missing admin guard (contrast with the sibling).** `fullTextSearchBlock` rejects the SQL method for non-admins (`if method == 2 && !IsAdminRoleContext(c)`). `fullTextSearchAssetContent` has no such check on its handler, so the SQL method is reachable by a reader. **method 2 : raw SQL, no statement guard.** Dispatch: `FullTextSearchAssetContent` case 2 → `searchAssetContentBySQL(query, …)`. After `filterQueryInvisibleChars` + `TrimSpace`, the statement is passed to `sql.SelectAssetContentsRawStmt(stmt, …)` → `queryAssetContent` → `assetContentDB.Query(query)` directly, with no `CheckSingleStatement`/`CheckReadonlyStatement`. The `assetContentDB` DSN sets no `mode=ro`/`_query_only`, so the handle is read-write (same `88250/go-sqlite3` fork). **method 3 : unescaped REGEXP concatenation.** Dispatch → `assetContentFieldRegexp(exp)`, which writes `(name REGEXP '<exp>' OR content REGEXP '<exp>')` by concatenation with **no** `'` escaping. `exp` reaches it after only `filterQueryInvisibleChars` (strips invisible characters, not quotes). The parallel block-search builder `fieldRegexp` performs `ReplaceAll(regexp, "'", "''")` before wrapping, this asset builder omits that step. A single quote in `exp` breaks out of the literal into SQL context. The result runs via `SelectAssetContentsRawStmtNoParse` → `queryAssetContent` → direct `assetContentDB.Query`, again with no single/read-only guard. **Post-hoc filter.** `FilterAssetContentByPublishAccess` runs on the results after the query executes; it filters rows and does not constrain the statement (same timing as the accepted `searchDocs`/`searchEmbedBlock` findings). **Handle / stacking / scope.** Read-write asset-content DB, `88250/go-sqlite3` stacking-capable driver, `ATTACH` available. The asset-content store spans notebooks cross-boundary. ### Impact An unauthenticated request (publish mode with auth disabled) or any publish `RoleReader` can, via method 2, execute arbitrary SQL on the read-write asset-content database, and via method 3, inject SQL through the unescaped `REGEXP` clause. Both permit cross-notebook read disclosure of asset-content data and, via the read-write handle and statement stacking, modification of database content and `ATTACH`-reachable files. No admin role or write permission through the normal API is required. Code execution is not reachable in the default build (no `load_extension`). ### PoC Steps 1. Create a doc with a heading and secret body (6806, admin token) `curl -s -X POST http://127.0.0.1:6806/api/notebook/createNotebook -H "Content-Type: application/json" -H "Authorization: Token g4wj3r04ntobe9m4" -d "{\"name\":\"F3\"}"` Take the returned notebook id as BOX, then: `curl -s -X POST http://127.0.0.1:6806/api/filetree/createDocWithMd -H "Content-Type: application/json" -H "Authorization: Token g4wj3r04ntobe9m4" -d "{\"notebook\":\"BOX\",\"path\":\"/f3-secret\",\"markdown\":\"## SecretSection\n\nUNIQUE_MARKER_99 hidden body text\"}"` The returned string is the doc root id → DOC. 2. Get the heading block id (admin SQL on 68 `curl -s -X POST http://127.0.0.1:6806/api/notebook/createNotebook -H "Content-Type: application/json" -H "Authorization: Token g4wj3r04ntobe9m4" -d "{\"name\":\"F3\"}"` Take the returned notebook id as BOX, then: `curl -s -X POST http://127.0.0.1:6806/api/fintent-Type: application/json" -H"Authorization: Token g4wj3r04ntobe9m4" -d "{\"notebook\":\"BOX\",\"path\":\"/f3-secret\",\"markdown\":\"## SecretSection\n\nUNIQUE_MARKER_99 hidden body text\"}"` The returned string is the doc root id → DOC. 2. Get the heading block id (admin SQL on 6806) `curl -s -X POST http://127.0.0.1:6806/api/query/sql -H "Content-Type: application/json" -H "Authorization: Token g4wj3r04ntob

**CVE:** This vulnerability corresponds to [CVE-2026-68587](https://nvd.nist.gov/vuln/detail/CVE-2026-68587). ### Summary Three "heading transaction" endpoints `/api/block/getHeadingDeleteTransaction`, `/api/block/getHeadingLevelTransaction`, and `/api/block/getHeadingInsertTransaction` return the rendered block DOM of a heading and its subtree in the computed transaction payload, with no publish-access check. They are gated by `CheckAuth` only, so they are reachable by the publish `RoleReader` token, and by the anonymous account when `Publish.Auth.Enable` is `false`. Despite their write-implying names, these endpoints perform no mutation on this path, they compute a transaction object and return it, and that object contains `RenderNodeBlockDOM` output. As a result, an anonymous reader who supplies a heading block ID can read the full rendered content of a document that has been explicitly marked publish-disabled by an administrator, content that the reader-facing `/api/filetree/getDoc` path correctly refuses to return. ### Details **Route / auth tier.** All three routes are registered `CheckAuth`-only (no `CheckAdminRole`). `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. **No publish-access filter.** `GetHeadingDeleteTransaction` / `GetHeadingLevelTransaction` / `GetHeadingInsertTransaction` load the heading's block tree and render its DOM into the returned transaction's operation data. None of the three invokes `IsReadOnlyRoleContext` / the publish-access filter that the reader-safe content path (`getDoc`) applies. The reader-facing content endpoints (`getDoc`, and the `CheckAdminRole`-gated `getBlockDOM`/`getBlockKramdown`) treat rendered block DOM as gated content; these three transaction endpoints return the same rendered DOM without that gate. **Write-implying name, read behavior.** On this code path the endpoints only *compute* the transaction (e.g. the `undoOperations` a delete would produce) and return it; nothing is deleted or modified. The returned operation data includes the rendered HTML of the heading subtree. This mismatch, mutation-shaped name, content-returning behavior is why the gap is easy to miss. ### Proof of Concept Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). `DOC` is a document containing a heading `HEADING` whose body contains the unique marker `UNIQUE_MARKER_99`, and `DOC` is marked publish-disabled by the administrator. **1. Confirm the document is publish-disabled (admin action, the boundary that should block reads):** ``` POST http://127.0.0.1:6806/api/filetree/setPublishAccess Authorization: Token <admin-token> {"id":"DOC","visible":false,"password":"","disable":true} ``` **2. Baseline: the reader-safe content path correctly blocks it (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/filetree/getDoc {"id":"DOC"} ``` Returns the blocked/placeholder response, the publish filter is applied, no content. **3. Disclosure: the transaction endpoint returns the content (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/block/getHeadingDeleteTransaction {"id":"HEADING"} ``` Returns HTTP 200; `data.undoOperations[].data` contains the rendered HTML of the heading subtree, including the hidden body text `UNIQUE_MARKER_99`. Nothing is deleted — the endpoint only computes the transaction. This is the full content of a publish-disabled document returned to an anonymous reader. **4. Sibling endpoints: same disclosure, same input:** ``` POST http://127.0.0.1:6808/api/block/getHeadingLevelTransaction {"id":"HEADING","level":2} POST http://127.0.0.1:6808/api/block/getHeadingInsertTransaction {"id":"HEADING"} ``` Both return the rendered DOM of the heading subtree in their operation data. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` who supplies a heading block ID can read the full rendered content of a publish-disabled document, defeating a boundary the administrator explicitly configured. **Precondition:** the request requires the target heading's block ID. Block IDs are high-entropy and are not returned by this endpoint, so this endpoint alone does not permit untargeted enumeration of arbitrary documents. However, block/heading IDs for publish-disabled documents are obtainable from other `CheckAuth`-only endpoints that lack the publish-access filter (the publish-boundary handler set reported separately, e.g. `getHeadingChildrenIDs`). Chained with such an ID source, this yields end-to-end unauthenticated full-content disclosure of publish-disabled documents. Presented standalone, the attacker must already possess the heading ID. Impact is confidentiality-only: these endpoints return content but do not (on this path) modify data. No admin role, CSRF token, or write permission is required. Encrypted notebooks

**CVE:** This vulnerability corresponds to [CVE-2026-68586](https://nvd.nist.gov/vuln/detail/CVE-2026-68586). ### Summary The backlink API splits into list endpoints (which documents reference a block) and content endpoints (the rendered text of those referencing blocks). The list endpoints apply a publish-access filter, the content endpoints do not. As a result, `/api/ref/getBacklinkDoc` and `/api/ref/getBackmentionDoc` return the rendered DOM of blocks belonging to a publish-forbidden document to an anonymous reader, with no access check. Both content endpoints are gated by `CheckAuth` only, reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details The asymmetry between the list and content sides is the tell that this is an oversight, not intended behavior: | Endpoint | Returns | Publish-access filter | Route | |---|---|---|---| | `getBacklink` | list (`*Path`) | `FilterPathsByPublishAccess` - present | `CheckAuth` | | `getBacklink2` | list (`*Path`) | `FilterPathsByPublishAccess` - present | `CheckAuth` | | `getBacklinkDoc` | rendered DOM | none | `CheckAuth` | | `getBackmentionDoc` | rendered DOM | none | `CheckAuth` | `model/backlink.go` contains no publish-access reference anywhere, and `Backlink.DOM` is the rendered HTML of the referencing blocks. `getBacklinkDoc(defID, refTreeID)` returns the rendered content of blocks in `refTreeID` - including a publish-forbidden, publish-disabled, or password-protected document with no access check. The filtered list siblings (`getBacklink`/`getBacklink2`) demonstrate that the publish boundary is meant to apply to this data; the content endpoints simply omit it. A reader is not limited to the filtered backlink list, they call `getBacklinkDoc` directly with any `refTreeID`. This also yields a reference-existence oracle: the response reveals whether the forbidden document `refTreeID` references the block `defID`. ### Proof of Concept Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a publish-forbidden document `D` (`REFTREEID`) whose body contains the unique marker `SECRET_MARKER_77` and which references a block `DEFID` in a separate known document. **1. Mark the target document publish-forbidden (admin action, the boundary that should block reads):** ``` POST http://127.0.0.1:6806/api/filetree/setPublishAccess Authorization: Token <admin-token> {"id":"REFTREEID","visible":false,"password":"","disable":true} ``` **2. Baseline: the list endpoint correctly hides the forbidden doc from the reader (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/ref/getBacklink2 {"id":"DEFID","k":"","mk":""} ``` The returned backlinks do not include the forbidden document `D`, the list side is filtered. **3. Disclosure: the content endpoint returns the forbidden doc's blocks anyway (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/ref/getBacklinkDoc {"defID":"DEFID","refTreeID":"REFTREEID","keyword":""} ``` Returns HTTP 200; `data.backlinks[].dom` contains `SECRET_MARKER_77`, the rendered content of the publish-forbidden document, returned to an anonymous reader. `getBackmentionDoc` behaves identically for mention-type references. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader`, can read the rendered content of a publish-forbidden document's referencing blocks, defeating a boundary the administrator explicitly configured, and can determine whether a forbidden document references a given block (a reference-existence oracle). **Precondition (stated honestly):** the request requires `refTreeID` (the forbidden document's ID) and `defID` (a block it references). `defID` may be any published/known block, so if the forbidden document references any public content, `defID` is known and only `refTreeID` need be supplied. Block/document IDs for forbidden documents are also obtainable from other `CheckAuth`-only endpoints that lack the publish-access filter (reported separately). This endpoint alone does not enumerate arbitrary documents; it discloses content once an ID is known. Impact is confidentiality-only: content disclosure plus a reference-existence oracle, no modification. No admin role, CSRF token, or write permission is required. Encrypted notebooks are out of scope. ### Suggested fix Apply the same publish-access check the list siblings use. In `getBacklinkDoc`/`getBackmentionDoc`, filter each `Backlink` by its source document's box/path via `CheckPathAccessableByPublishIgnore` plus the publish-password cookie check consistent with `FilterPathsByPublishAccess` in `getBacklink`/`getBacklink2`. Any endpoint returning rendered block DOM should enforce the same publish boundary as the corresponding list endpoint.

**CVE:** This vulnerability corresponds to [CVE-2026-68585](https://nvd.nist.gov/vuln/detail/CVE-2026-68585). ### Summary The `/api/block/getBlockInfo` endpoint returns document root metadata including the document title (`rootTitle`) for a block in a publish-forbidden document, with no publish-access check. Its sibling `/api/block/getDocInfo` applies the publish-access filter, `getBlockInfo` does not. Both are gated by `CheckAuth` only, so `getBlockInfo` is reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. ### Details The list/info side of this API is filtered while the block-info twin is not the asymmetry indicates an oversight rather than intended behavior: | Endpoint | Returns | Publish-access filter | Route | |---|---|---|---| | `getDocInfo` | document info/metadata | present | `CheckAuth` | | `getBlockInfo` | `box, path, rootID, rootTitle, rootChildID, rootIcon` | none | `CheckAuth` | `getBlockInfo` takes a caller-supplied block ID, validates only its format, and returns the containing document's root metadata including `rootTitle` (the document title) with no `IsReadOnlyRoleContext` / publish-access check. Because `getDocInfo` performs the filtering for equivalent data, the boundary is clearly meant to apply here; `getBlockInfo` omits it. ### Proof of Concept Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a publish-forbidden document `D` whose title is a unique marker, containing a block `BLOCKID`. **1. Mark the document publish-forbidden (admin action):** ``` POST http://127.0.0.1:6806/api/filetree/setPublishAccess Authorization: Token <admin-token> {"id":"DOC","visible":false,"password":"","disable":true} ``` **2. Disclosure: the block-info endpoint returns the forbidden doc's title (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/block/getBlockInfo {"id":"BLOCKID"} ``` Returns HTTP 200 with `data.rootTitle` set to the publish-forbidden document's title, along with `box`, `path`, `rootID`, and `rootIcon`. This document's title is not returned by the reader-facing filtered paths. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the title and root metadata (notebook, path, root ID, icon) of a publish-forbidden document by supplying a block ID from it. This discloses the existence, title, and location of documents an administrator marked as excluded from publishing. **Precondition and scope (stated honestly):** the request requires a block ID from the target document; this endpoint does not enumerate arbitrary documents. The disclosure is limited to document metadata, title, notebook, path, root ID, icon — not the document body. Block IDs for forbidden documents are obtainable from other `CheckAuth`-only endpoints that lack the publish-access filter (reported separately). Impact is confidentiality-only, limited to metadata; no content body, no modification. Encrypted notebooks are out of scope. ### Suggested fix Apply the same publish-access check `getDocInfo` uses to `getBlockInfo` before returning root metadata, resolve the block's document and enforce `IsReadOnlyRoleContext` / the publish-access filter, consistent with the sibling endpoint.

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 versions before v3.7.3 contain an authentication bypass vulnerability in publish mode where content-returning endpoints getHeadingChildrenDOM, getHeading*Transaction, and getBacklinkDoc perform no password check despite protecting the primary getDoc endpoint. Anonymous attackers can retrieve full content of password-protected documents by obtaining internal block IDs from reader-accessible endpoints and calling unprotected content endpoints to bypass the password gate.

SiYuan before v3.7.2 fails to escape the title-img Individual Attribute List value when rendering Gallery and Kanban cover images, allowing stored cross-site scripting via unescaped style attribute interpolation. Attackers with editor permissions can inject onload handlers that execute arbitrary code in the Electron renderer with full Node.js access when victims open affected documents.

SiYuan desktop before v3.7.2 contains a reflected cross-site scripting vulnerability in the bazaar plugin readme handler that allows attackers to execute arbitrary code by crafting a malicious siyuan:// deep link. Attackers can inject HTML payloads via the plugin name parameter that execute with full Node.js access through insertAdjacentHTML rendering in an insecurely configured Electron renderer.

SiYuan before v3.7.3 contains stored and reflected cross-site scripting vulnerabilities in SVG sanitization that allows authenticated attackers to execute scripts by bypassing the HTML parser-based cleaner. Attackers can hide script tags within desc, style, or noscript elements which the HTML parser treats as raw text but browsers interpret as executable SVG content when served as image/svg+xml, enabling script execution in the application origin.

SiYuan before v3.7.2 contains a missing authorization vulnerability in the POST /mcp kernel endpoint, which is gated only by a general auth check (model.CheckAuth) with no admin-role or read-only enforcement. This exposes 31 MCP tools, including a file tool with list/read/write/delete/rename/copy actions across the entire workspace. When the Publish server is enabled in anonymous mode (Conf.Publish.Enable=true and Conf.Publish.Auth.Enable=false), the Publish reverse proxy attaches an anonymous RoleReader JWT to proxied requests, allowing a remote unauthenticated attacker to reach /mcp. The attacker can read conf/conf.json to extract accessAuthCode, api.token, and cookieKey in plaintext, write arbitrary files in the workspace, and plant a plugin into data/plugins/ that executes with nodeIntegration:true and no contextIsolation on the next desktop launch, leading to administrator takeover.

SiYuan before v3.7.2 contains a path traversal vulnerability in the /export/temp/ short-circuit branch of the serveExport handler (kernel/server/serve.go). Unlike the main export branch, this branch joins the raw, percent-decoded request path with util.TempDir and serves the file without the IsSubPath or IsSensitivePath checks added in the earlier export-disclosure hardening (GHSA-6865-qjcf-286f). An authenticated attacker can send percent-encoded traversal sequences (e.g. /export/temp/%2e%2e/.../etc/passwd, where %2e%2e is decoded to '..') to read arbitrary files outside TempDir, including /etc/passwd, SSH keys (~/.ssh/*), and SiYuan workspace *.db and *.log files, bypassing the sensitive-file protection.

SiYuan before v3.7.2 contains a cross-site scripting vulnerability in the siyuan:// protocol handler. When a siyuan://plugins/<name> link references a name that is not an installed plugin, the application opens a custom tab and inserts the link's icon parameter into the tab header via innerHTML without escaping it (app/src/layout/Tab.ts), allowing injection of an <img onerror=...> element. Because the SiYuan Desktop renderer runs with nodeIntegration:true, the injected JavaScript can access Node's require and call require('child_process').execSync(...), escalating the cross-site scripting into arbitrary operating-system command execution.

SiYuan before v3.7.2 contains a stored cross-site scripting vulnerability in Attribute View (database) cell rendering. A Template column value is rendered as HTML via text/template without auto-escaping, and EscapeHTML is only applied when HasUnclosedHtmlTag returns true; because balanced self-closing tags such as <img> are skipped by that check, a payload like <img src=x onerror=...> is stored unescaped and later inserted into the page via innerHTML, executing when the database is viewed. Because the desktop renderer runs with nodeIntegration enabled, the injected script can reach require and escalate to arbitrary command execution.

SiYuan is an open-source personal knowledge management system. Prior to 3.7.1, POST /api/file/globalCopyFiles accepts attacker-supplied absolute source paths and relies on util.IsSensitivePath in kernel/util/path.go, whose denylist misses common home-directory credential files such as .git-credentials, .netrc, .pgpass, .kube/config, .docker/config.json, and .gnupg, allowing an authenticated administrator or API-token user to copy those files into the workspace and exfiltrate them through the file API. This issue is fixed in versions 3.7.1-alpha.2 and 3.7.1.

SiYuan is an open-source personal knowledge management system. Prior to 3.7.1, the /api/storage/getCriteria endpoint returns saved search criteria from data/storage/criteria.json without the publish-access filtering used by sibling storage endpoints, allowing a publish-mode Reader to read private document paths, notebook, document, and block IDs, and search and replace keywords for unpublished documents. This issue is fixed in versions 3.7.1.