Summary
SiYuan exposes rendered block DOM content via specific heading-related endpoints without proper publish-access checks, leading to unauthorized information disclosure.
Anonymous users or holders of RoleReader tokens can query these endpoints with a heading block ID to read full content from publish-disabled documents that are intended to remain restricted.
Affected context
This vulnerability occurs in SiYuan deployments that expose the getHeadingDeleteTransaction, getHeadingLevelTransaction, and getHeadingInsertTransaction endpoints to readers or anonymous users.
It becomes relevant when documents are marked as publish-disabled or otherwise restricted, but heading-level operations are still available through the API.
In such configurations, the system may render and return full block DOM content associated with a supplied heading ID without consistently enforcing publish-access controls.
Exploit preconditions
- Attack surface: HTTP API endpoints handling heading operations (
getHeadingDeleteTransaction,getHeadingLevelTransaction,getHeadingInsertTransaction). - Required access: Ability to send requests as an anonymous reader or using a RoleReader publish token.
- Trigger point: Supplying the ID of a heading block that belongs to a publish-disabled or restricted document.
- Why exploitation is possible: The endpoints return rendered block DOM content and perform incomplete authorization checks, failing to verify that the caller is allowed to access publish-disabled documents.
Why this happens
The underlying issue is a missing or incomplete authorization check on content returned by heading-related transactions.
While documents may be configured as publish-disabled or restricted, the API paths that manipulate headings still render and expose block DOM content without re-evaluating publish-access permissions.
This aligns with CWE-862: Missing Authorization, where a resource or operation that should be guarded by an access-control decision is reachable in practice without appropriate permission checks.
Potential impact
- Disclosure of the full text and structure of publish-disabled or restricted documents.
- Exposure of sensitive or internal information that authors intended to keep private.
- Unintended leakage of metadata, headings, and contextual relationships between blocks.
- Assistance to attackers in mapping document structures for further attacks or social engineering.
General mitigation guidance
Mitigation generally focuses on enforcing consistent authorization checks across all content-related endpoints, not just primary document views.
Common secure patterns include:
- Centralizing access-control decisions so that publish status and user roles are applied uniformly to every API that can render or return document content.
- Designing heading and block operations to operate on identifiers only, and deferring content rendering to layers that enforce publish-access policies.
- Applying the principle of least privilege by ensuring reader roles and tokens cannot access operations that may expose non-published content.
- Implementing defense-in-depth checks where content rendering routines verify document visibility before returning any block DOM data.
How teams detect issues like this
Detection efforts can focus on identifying endpoints that bypass central authorization logic or return content without verifying publish-access state.
Approaches include:
- Static analysis and architectural reviews to locate direct content rendering calls that do not pass through a shared authorization layer.
- Code review checklists that require explicit access-control verification for any API method returning document or block DOM content.
- Logging and monitoring of heading-related transactions, looking for access to publish-disabled documents originating from anonymous or low-privilege roles.
- Security testing and automated API scanning to exercise heading APIs with restricted document IDs and verify whether unauthorized content is disclosed.
