Listen to this Post
SiYuan’s publish mode implements a “protected” access level,
which makes documents publicly listed but password-protected for reading.
The primary endpoint getDoc correctly enforces the password
via FilterContentByPublishAccess.
However, several other content-retrieving API endpoints completely omit this password check.
These vulnerable endpoints include getHeadingChildrenDOM,
getHeadingDeleteTransaction, getHeadingLevelTransaction,
getHeadingInsertTransaction, getBacklinkDoc, and getBackmentionDoc.
Each of these endpoints takes a block ID as input
and returns the full rendered DOM of the corresponding block,
regardless of the parent document’s password status.
The vulnerability is exacerbated by the fact that protected documents
are publicly listed via listDocsByPath.
An anonymous attacker can obtain the root ID of any protected document
simply by listing published documents.
To acquire internal block/heading IDs, the attacker can leverage
the searchEmbedBlock endpoint.
Although searchEmbedBlock applies a post-query filter
that blanks the content field, it retains the block IDs in the response.
This design flaw allows an attacker to enumerate heading IDs
belonging to the protected document.
With a valid heading ID in hand, the attacker directly calls
getHeadingChildrenDOM (or any other listed vulnerable endpoint)
without any password or authentication token.
The server returns the full rendered HTML content of that heading subtree,
including all sensitive text that should be behind the password gate.
The complete exploit chain has been reproduced on a live instance
where a document with a unique marker was fully retrieved without credentials.
This bypass effectively nullifies the protection mechanism,
as the primary path is blocked but the secondary endpoints bypass it entirely.
DailyCVE Form:
Platform: SiYuan Note
Version: All vulnerable versions
Vulnerability : Access Control Bypass
Severity: Critical
date: 2026-09-03
Prediction: 2026-09-15
What Undercode Say:
Step 1: Confirm primary password gate blocks access
curl -X POST http://127.0.0.1:6808/api/filetree/getDoc \
-H “Content-Type: application/json” \
-d ‘{“id”:”PROTECTED_DOC_ROOT_ID”}’
Step 2: Leak internal heading IDs via searchEmbedBlock (content filtered, IDs retained)
curl -X POST http://127.0.0.1:6808/api/search/searchEmbedBlock \
-H “Content-Type: application/json” \
-d ‘{“stmt”:”SELECT FROM blocks WHERE root_id=’\”PROTECTED_DOC_ROOT_ID’\” AND type=’\”h’\””}’
Step 3: Retrieve full protected content without password using leaked heading ID
curl -X POST http://127.0.0.1:6808/api/block/getHeadingChildrenDOM \
-H “Content-Type: application/json” \
-d ‘{“id”:”LEAKED_HEADING_ID”}’
Alternative endpoints providing the same password-free content retrieval:
getHeadingDeleteTransaction, getHeadingLevelTransaction,
getHeadingInsertTransaction, getBacklinkDoc, getBackmentionDoc
Exploit: (Educational Purposes!)
- Enumerate public documents to obtain the root_id of a target marked “protected”.
- Issue a searchEmbedBlock SQL query filtering heading blocks under that root_id.
- Parse the JSON response to extract the heading IDs (despite blanked content).
- Call getHeadingChildrenDOM with the extracted heading ID to receive full rendered DOM.
- Repeat for any heading ID to reconstruct the entire protected document’s body.
Protection: from this CVE
Apply the same publish-password check (FilterContentByPublishAccess and IsReadOnlyRoleContext plus password-cookie) to every content-returning endpoint: getHeadingChildrenDOM, all three getHeadingTransaction handlers, and getBacklinkDoc/getBackmentionDoc. Separately, modify FilterEmbedBlocksByPublishAccess to completely omit filtered blocks instead of blanking content while retaining IDs. The durable fix is to enforce the access boundary in the shared render/DOM pipeline rather than per-handler.
Impact:
Confidentiality breach. An unauthenticated remote attacker (with publish mode auth disabled) can read the full contents of any password-protected published document without supplying the password. The access control mechanism is completely defeated, exposing all sensitive information stored within these protected documents. No data modification occurs, but the confidentiality impact is total for published protected content.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
