Threats Tagged 'ghsa-7j72-f6wg-cxw6'
View all threats tagged with 'ghsa-7j72-f6wg-cxw6'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'ghsa-7j72-f6wg-cxw6'
Click on any threat for detailed analysis and mitigation recommendations
Kernel: SiYuan: Anonymous publish-password authentication bypass via getHeadingChildrenDOM / getHeading*Transaction / getBacklinkDoc (publish mode) 0 **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 ID Join the discussion | GCVE Database | 09/03/2026, 21:22:42 UTC Added: 09/04/2026, 14:26:37 UTC |
Showing 1 to 1 of 1 result