Listen to this Post
CVE-2026-72795 exposes a critical access control flaw in SiYuan Note’s publish module. The vulnerable endpoints, `/api/block/getBlockDOMWithEmbed` and /api/block/getBlockDOMsWithEmbed, are intended to return the DOM structure of a requested block while respecting publish permissions. These routes are gated by the `CheckAuth` middleware, making them reachable by a `publishRoleReader` token or even anonymously when `Publish.Auth.Enable` is set to false. The primary gate correctly validates publish access for the top-level block ID supplied in the request. However, the vulnerability manifests when that block contains an embed (transclusion) block, i.e., a `NodeBlockQueryEmbed` node. The server processes this embed by extracting its SQL query and executing `sql.SelectBlocksRawStmtInBox` to retrieve all matching blocks across the entire workspace. The core problem lies in the function `resolveEmbedContentInBox` (located in kernel/model/block.go:976), which is called downstream from the initial guard. This function walks the syntax tree, executes the embed query, builds HTML content for each matched block, and inlines it via SetIALAttr("embed-content"). Critically, `resolveEmbedContentInBox` takes no `publishAccess` parameter and performs zero filtering—no calls to CheckBlockIdAccessableByPublishAccess, CheckPathAccessable, or FilterEmbedBlocks. It blindly trusts the results of the embed query, returning content from blocks residing in hidden, forbidden, or password-protected documents. The reader does not need to manipulate the request; simply viewing any published document containing an embed query is sufficient to trigger the leak passively. For comparison, a sibling endpoint, /api/search/getEmbedBlock, exists for the same search functionality and correctly applies `model.FilterEmbedBlocksByPublishAccess` for reader roles, filtering out unauthorized results. The plural route `getBlockDOMsWithEmbed` applies a per-id publish gate, which is accurate but irrelevant because the downstream `resolveEmbedContentInBox` bypasses that context entirely. This inconsistency means that while the requested block is properly vetted, every block matched by its internal embed query is returned unfiltered, exposing sensitive workspace data that should remain private. The differential response between the DOM endpoints and the filtered `getEmbedBlock` endpoint confirms the absence of access controls in the embed resolution path. This vulnerability affects all publish-enabled instances where aggregation queries span across documents with mixed visibility tiers.
DailyCVE Form:
Platform: SiYuan Note
Version: All pre-patch
Vulnerability: Access Control Bypass
Severity: Medium
date: 2026-09-04
Prediction: 2026-10-15
What Undercode Say:
Vulnerable request - leaks private embed content
curl -X POST http://127.0.0.1:6808/api/block/getBlockDOMWithEmbed \
-H "Content-Type: application/json" \
-d '{"id":"<published_block_id_with_embed>"}'
Filtered sibling endpoint - correctly hides private blocks
curl -X POST http://127.0.0.1:6808/api/search/getEmbedBlock \
-H "Content-Type: application/json" \
-d '{"stmt":"<same_embed_query>"}'
Plural route also vulnerable for each requested id
curl -X POST http://127.0.0.1:6808/api/block/getBlockDOMsWithEmbed \
-H "Content-Type: application/json" \
-d '{"ids":["<published_block_id>"]}'
Exploit: (Educational Purposes!)
- Enable publish mode on a SiYuan instance (default port 6808).
- Ensure `Publish.Auth.Enable` is false for anonymous access, or obtain a valid `publishRoleReader` token.
- Identify a published block that contains an embed query (e.g., a dashboard aggregating “all TODOs” or blocks with a specific tag).
- Send a POST request to `/api/block/getBlockDOMWithEmbed` with the block’s ID.
- Inspect the response DOM; locate the `embed-content` attributes which contain the full HTML of blocks from non-published or password-protected documents.
- Compare with the response from `/api/search/getEmbedBlock` using the same query—observe that private blocks are absent there, confirming the leak.
Protection:
- Thread the request’s `publishAccess` context through
resolveEmbedContentInBox. - Within
resolveEmbedContentInBox, when `IsReadOnlyRoleContext` is true, apply `CheckBlockIdAccessableByPublishAccess` and password-tier checks to each matched block. - Drop any block that fails the checks before writing its content into the `embed-content` attribute.
- Align the filtering logic in `resolveEmbedContentInBox` with the existing `FilterEmbedBlocksByPublishAccess` used by
/api/search/getEmbedBlock.
Impact:
- An anonymous or low-privilege reader can exfiltrate the content of arbitrary blocks from documents that are not published, marked hidden, marked forbidden, or protected by a publish password.
- The disclosure occurs passively when viewing any published document that contains an embed query, requiring no special attacker control.
- The volume of exposed data is bounded only by the scope of the author’s embed queries, which often span the entire workspace for dashboards and aggregations.
- Confidentiality is fully compromised for matched blocks; integrity and availability remain unaffected.
🎯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
