GHSA-7J72-F6WG-CXW6
Vulnerability from github – Published: 2026-09-03 21:22 – Updated: 2026-09-08 18:03CVE: This vulnerability corresponds to 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:
getDoc(protectedDoc)→ returns the password-required placeholder (correctly blocked).searchEmbedBlockwith a statement selecting heading blocks for the document's root ID → returns the heading IDs (content filtered, IDs retained).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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260721020826-2d069dce84a2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-68584"
],
"database_specific": {
"cwe_ids": [
"CWE-288"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T21:22:42Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-68584](https://nvd.nist.gov/vuln/detail/CVE-2026-68584).\n\n### Summary\n\nSiYuan\u0027s publish mode defines a \"protected\" access level: a document that is publicly listed but requires a password to read (per the product\u0027s own UI help text, protected = \"Publicly visible, requires password to access\"). The password is enforced on the primary content path (`getDoc`, via `FilterContentByPublishAccess`).\n\nSeveral 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\u0027s 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.\n\n### Details\n\n**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.\n\n**Content endpoints with no password check (all `CheckAuth`-only):**\n- `getHeadingChildrenDOM` returns rendered DOM of a heading subtree.\n- `getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` return rendered heading DOM in the computed transaction payload (no mutation occurs on this path).\n- `getBacklinkDoc`/`getBackmentionDoc` return rendered DOM of referencing blocks.\n\nNone of these invokes the publish-password check that `getDoc` applies. Each converts a block ID into full rendered content regardless of the containing document\u0027s protected/password status.\n\n**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\u0027s root ID. The document\u0027s 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\u0027s internal heading IDs. (Other reader-reachable endpoints also leak block IDs, the vulnerability does not depend on any single ID source.)\n\n**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:\n\n1. `getDoc(protectedDoc)` \u2192 returns the password-required placeholder (correctly blocked).\n2. `searchEmbedBlock` with a statement selecting heading blocks for the document\u0027s root ID \u2192 returns the heading IDs (content filtered, IDs retained).\n3. `getHeadingChildrenDOM(headingId)` \u2192 returns the full rendered body of the protected document, including its protected content.\n\nThe password gate that step 1 enforces is entirely bypassed by step 3.\n\n### Proof of Concept\n\nReproduced 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`.\n\n**1. Confirm the password gate blocks the primary path (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/filetree/getDoc\n{\"id\":\"PROTECTED_DOC\"}\n```\nReturns the password-required placeholder correctly blocked.\n\n**2. Leak the protected document\u0027s heading ID (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/search/searchEmbedBlock\n{\"stmt\":\"SELECT * FROM blocks WHERE root_id=\u0027PROTECTED_DOC\u0027 AND type=\u0027h\u0027\"}\n```\nReturns heading blocks with their IDs; the content field is filtered but the block ID is retained.\n\n**3. Retrieve the protected content without the password (anonymous, port 6808):**\n```\nPOST http://127.0.0.1:6808/api/block/getHeadingChildrenDOM\n{\"id\":\"HEADING_ID\"}\n```\nReturns HTTP 200 with the rendered body of the protected document, including `TOP_SECRET_CRITICAL_123` retrieved with no token and no password.\n\n`getHeadingDeleteTransaction`/`getHeadingLevelTransaction`/`getHeadingInsertTransaction` and `getBacklinkDoc`/ `getBackmentionDoc` provide the same password-free content retrieval given a block ID from the protected document.\n\n### Impact\n\nAn 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.\n\n### Suggested fix\n\nApply 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\u0027s 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.",
"id": "GHSA-7j72-f6wg-cxw6",
"modified": "2026-09-08T18:03:33Z",
"published": "2026-09-03T21:22:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-7j72-f6wg-cxw6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68584"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/2d069dce84a25c959ef0093c72c98e05778ef218"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-authentication-bypass-via-content-endpoints"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: Anonymous publish-password authentication bypass via getHeadingChildrenDOM / getHeading*Transaction / getBacklinkDoc (publish mode)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.