GHSA-7j72-f6wg-cxw6: SiYuan: auth bypass leaks password-protected doc content

**CVE:** This vulnerability corresponds to [CVE-2026-68584](https://nvd.nist.gov/vuln/detail/CVE-2026-68584). ### Summary SiYuan's publish mode defines a "protected" access level: a document that is publicly listed but requires a password to read (per the product's own UI help text, protected = "Publicly visible, requires password to access"). The password is enforced on the primary content path (`getDoc`, via `FilterContentByPublishAccess`). Several other content-returning endpoints `getHeadingChildrenDOM`, `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/ `getHeadingInsertTransaction`, and `getBacklinkDoc`/`getBackmentionDoc` return rendered block DOM with **no password check at all**. Combined with reader-reachable endpoints that leak a protected document's internal block IDs, an anonymous reader can retrieve the full body of a password-protected document without the password. This has been reproduced end-to-end on a live instance. ### Details **The password control and where it is enforced.** Publish access has five levels encoded in `visible`/`password`/`disable`: public, protected (password), hidden, private (password), forbidden. `getDoc` correctly enforces the password for protected/private documents via `FilterContentByPublishAccess`. The bug is that other content endpoints do not. **Content endpoints with no password check (all `CheckAuth`-only):** - `getHeadingChildrenDOM` returns rendered DOM of a heading subtree. - `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` return rendered heading DOM in the computed transaction payload (no mutation occurs on this path). - `getBacklinkDoc`/`getBackmentionDoc` return rendered DOM of referencing blocks. None of these invokes the publish-password check that `getDoc` applies. Each converts a block ID into full rendered content regardless of the containing document's protected/password status. **The ID-leak that removes the precondition.** A protected document is, by design, publicly listed (`listDocsByPath` filters on `visible`, and protected documents are visible), so an anonymous reader obtains the document's root ID. The document's internal block/heading IDs are then obtainable from reader-reachable endpoints notably the `searchEmbedBlock` endpoint (reported separately), whose post-query filter `FilterEmbedBlocksByPublishAccess` **replaces the content string but retains the block ID**. So the "filtered" search still yields the protected document's internal heading IDs. (Other reader-reachable endpoints also leak block IDs, the vulnerability does not depend on any single ID source.) **The chain, reproduced on a live instance.** Against a real protected document (password set), an anonymous reader on port 6808 with no token and no password: 1. `getDoc(protectedDoc)` → returns the password-required placeholder (correctly blocked). 2. `searchEmbedBlock` with a statement selecting heading blocks for the document's root ID → returns the heading IDs (content filtered, IDs retained). 3. `getHeadingChildrenDOM(headingId)` → returns the full rendered body of the protected document, including its protected content. The password gate that step 1 enforces is entirely bypassed by step 3. ### Proof of Concept Reproduced on a local instance (SiYuan running locally, publish mode enabled on port 6808, publish Basic Auth disabled). Setup: a document marked "protected" with password, whose body contains the unique marker `TOP_SECRET_CRITICAL_123`. **1. Confirm the password gate blocks the primary path (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/filetree/getDoc {"id":"PROTECTED_DOC"} ``` Returns the password-required placeholder correctly blocked. **2. Leak the protected document's heading ID (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/search/searchEmbedBlock {"stmt":"SELECT * FROM blocks WHERE root_id='PROTECTED_DOC' AND type='h'"} ``` Returns heading blocks with their IDs; the content field is filtered but the block ID is retained. **3. Retrieve the protected content without the password (anonymous, port 6808):** ``` POST http://127.0.0.1:6808/api/block/getHeadingChildrenDOM {"id":"HEADING_ID"} ``` Returns HTTP 200 with the rendered body of the protected document, including `TOP_SECRET_CRITICAL_123` retrieved with no token and no password. `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` and `getBacklinkDoc`/ `getBackmentionDoc` provide the same password-free content retrieval given a block ID from the protected document. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read the full content of a password-protected published document without the password, defeating the "protected" access control the product documents as a password gate. The core defect is that these content-returning endpoints perform no publish-password check; the ID-leak endpoints (multiple sources) supply the block IDs that make the bypass reachable anonymously and untargeted. Impact is confidentiality-only (content disclosure); no modification occurs on these paths. Encrypted notebooks are out of scope. ### Suggested fix Apply the publish-password/publish-access check that `getDoc` uses (`FilterContentByPublishAccess`/`IsReadOnlyRoleContext` plus the password-cookie check) to every content-returning endpoint: `getHeadingChildrenDOM`, the three `getHeading*Transaction` handlers, and `getBacklinkDoc`/`getBackmentionDoc`. Separately, `FilterEmbedBlocksByPublishAccess` should omit filtered blocks entirely rather than blanking the content while retaining the ID, so that filtered results cannot be used to enumerate a protected document's internal block IDs. The durable fix is to enforce the publish boundary in the shared render/DOM path rather than per-handler, since any content endpoint that omits the check reintroduces this class.

An attacker discovers a SiYuan publish instance exposed to the internet (e.g., via search-engine indexing or port scanning for 6808) and finds a document listed as password-protected. Instead of attempting to guess the password, they call the public listDocsByPath/search endpoint to learn the document's root ID, then send an unauthenticated POST to searchEmbedBlock with a SQL-like statement selecting heading blocks for that root ID — the response strips the protected content string but still returns the internal heading block IDs. The attacker then feeds one of those IDs into getHeadingChildrenDOM (or getBacklinkDoc/getBackmentionDoc), which returns the fully rendered DOM of that heading subtree with no password check at all, disclosing the protected document's real content. The entire chain is three scripted HTTP requests, requires no account, and can be automated to sweep every publicly-listed protected document on an instance.