CVE: 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).searchEmbedBlock with 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.
References
Shirshakhtml Reporter
CVE: 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, viaFilterContentByPublishAccess).Several other content-returning endpoints
getHeadingChildrenDOM,getHeadingDeleteTransaction/getHeadingLevelTransaction/getHeadingInsertTransaction, andgetBacklinkDoc/getBackmentionDocreturn 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.getDoccorrectly enforces the password for protected/private documents viaFilterContentByPublishAccess. 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
getDocapplies. 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 (
listDocsByPathfilters onvisible, 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 thesearchEmbedBlockendpoint (reported separately), whose post-query filterFilterEmbedBlocksByPublishAccessreplaces 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):
Returns the password-required placeholder correctly blocked.
2. Leak the protected document's heading ID (anonymous, port 6808):
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):
Returns HTTP 200 with the rendered body of the protected document, including
TOP_SECRET_CRITICAL_123retrieved with no token and no password.getHeadingDeleteTransaction/getHeadingLevelTransaction/getHeadingInsertTransactionandgetBacklinkDoc/getBackmentionDocprovide 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
RoleReadercan 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
getDocuses (FilterContentByPublishAccess/IsReadOnlyRoleContextplus the password-cookie check) to every content-returning endpoint:getHeadingChildrenDOM, the threegetHeading*Transactionhandlers, andgetBacklinkDoc/getBackmentionDoc. Separately,FilterEmbedBlocksByPublishAccessshould 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.References