Summary
SiYuan: Anonymous publish-password authentication bypass via getHeadingChildrenDOM / getHeading*Transaction / getBacklinkDoc (publish mode)
CVE: This vulnerability corresponds to CVE-2026-68584.
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):
getHeadingChildrenDOMreturns rendered DOM of a heading subtree.getHeadingDeleteTransaction/getHeadingLevelTransaction/getHeadingInsertTransactionreturn rendered heading DOM in the computed transaction payload (no mutation occurs on this path).getBacklinkDoc/getBackmentionDocreturn 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.
CVE-2026-68584 has a CVSS score of 8.6 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260721020826-2d069dce84a2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-68584? CVE-2026-68584 is a high-severity security vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260721020826-2d069dce84a2. It is fixed in 0.0.0-20260721020826-2d069dce84a2.
- How severe is CVE-2026-68584? CVE-2026-68584 has a CVSS score of 8.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-68584? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260721020826-2d069dce84a2 is affected.
- Is there a fix for CVE-2026-68584? Yes. CVE-2026-68584 is fixed in 0.0.0-20260721020826-2d069dce84a2. Upgrade to this version or later.
- Is CVE-2026-68584 exploitable, and should I be worried? Whether CVE-2026-68584 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-68584 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-68584? Upgrade
github.com/siyuan-note/siyuan/kernelto 0.0.0-20260721020826-2d069dce84a2 or later.