Sep 4, 2026·7 min read·15 visits
An authorization bypass flaw in SiYuan's reference content retrieval API endpoints allows unauthorized readers to fetch the fully rendered DOM of publish-restricted documents using known document identifiers.
SiYuan is a privacy-first personal knowledge management system. In versions prior to v3.7.3, the application fails to apply publish-access filters to the getBacklinkDoc and getBackmentionDoc content endpoints (/api/ref/getBacklinkDoc and /api/ref/getBackmentionDoc). While the corresponding backlink list endpoints correctly filter out publish-forbidden documents, the content endpoints, which are only gated by high-level route authorization checks via CheckAuth, do not. Consequently, a user with low-privilege read access, or an anonymous reader when publish Basic Auth is disabled, can directly invoke these endpoints using a known publish-forbidden document's ID to retrieve its rendered DOM content or determine whether it references a specific target block.
SiYuan is an open-source, privacy-first personal knowledge management platform designed to organize and structure notes locally or via self-hosted servers. It features a robust publishing module that allows administrators to share select portions of their knowledge base with external readers. To restrict access to sensitive or unfinished notes, the platform implements a path-level publishing authorization schema. Administrators can flag specific files as publish-forbidden or password-protected, establishing a logical security boundary between public and private documentation.
The attack surface for this system is primarily exposed through its REST API endpoints, which handle note rendering and cross-reference queries. Among these endpoints are the backlink and backmention retrieval services, which map relationships between separate blocks of content. While the metadata listing APIs successfully filter out restricted paths, the content retrieval endpoints fail to enforce these exact same constraints, resulting in a classic authorization omission.
This vulnerability, tracked as CVE-2026-68586, belongs to the Missing Authorization (CWE-862) bug class. The security boundary is breached because the server evaluates the identity of the requester (authentication) but neglects to verify whether that specific identity is permitted to access the requested resource path (authorization). As a result, low-privileged or completely anonymous users can bypass the document visibility restrictions established by the administrator.
The core issue resides in the asymmetric application of authorization controls across the backlink API family. SiYuan distinguishes between the discovery of backlinks (determining which documents link to a block) and the retrieval of their content (rendering the actual text of those links). The discovery endpoints, such as getBacklink, query the system's index and filter the results using the FilterPathsByPublishAccess function. This sanitization step strips unauthorized document paths from the response before it is transmitted to the client.
In contrast, the content rendering endpoints, specifically /api/ref/getBacklinkDoc and /api/ref/getBackmentionDoc, do not execute any path-level validation. When a request is made, the routing engine only applies the CheckAuth middleware. This middleware is a coarse access check that validates whether the client session is recognized as an active reader or if the server allows anonymous read access. It does not inspect the parameters of the request body to verify if the client has permissions for the specific refTreeID (the document ID containing the reference).
Because the backend skips granular authorization checks for these endpoints, a logical flaw occurs. If a client possesses the unique identifier of a publish-restricted document, they can bypass the metadata listings entirely. By invoking the content endpoints directly with the target document's refTreeID, the server is forced to fetch, render, and return the sensitive DOM content without verifying the document's publication status.
The structural vulnerability in the backend was fixed by introducing validation checks in the kernel/api/ref.go file. Before the patch, the getBacklinkDoc and getBackmentionDoc request handlers did not check the publication status of the document requested via the refTreeID parameter. They directly parsed the inputs and invoked the internal rendering model. The following code comparison highlights the remediated control flow.
// Vulnerable Control Flow (Prior to Patch)
// The handler parsed the parameter but directly rendered the document
defID := arg["defID"].(string)
refTreeID := arg["refTreeID"].(string)
// Missing authorization verification check hereTo correct this oversight, developers added the isBacklinkDocAccessible helper function. This function determines whether the current request is running under a read-only role context, such as a public web viewer. If the context is read-only, the function delegates authorization to the model.CheckBlockIdAccessableByPublishAccess method, checking the refTreeID against the active publishing rules. If access is denied, the handler terminates early and returns an empty payload instead of the sensitive note content.
// Patched Control Flow in kernel/api/ref.go
func isBacklinkDocAccessible(c *gin.Context, refTreeID string) bool {
if !model.IsReadOnlyRoleContext(c) {
return true
}
// Validate the document ID against active publish-access rules
return model.CheckBlockIdAccessableByPublishAccess(c, model.GetPublishAccess(), refTreeID)
}
// Within getBacklinkDoc/getBackmentionDoc handler:
if !isBacklinkDocAccessible(c, refTreeID) {
ret.Data = map[string]any{
"backmentions": []*model.Backlink{},
"keywords": []string{},
}
return
}The corresponding validation logic in kernel/model/publish_access.go was also modularized. The function CheckBlockIdAccessableByPublishAccess was refactored to separate the retrieval of the block tree structure from the access evaluation itself. The newly created helper checkBlockTreeAccessableByPublishAccess checks if the path associated with the target notebook is hidden or password-protected. This modular approach ensures that the endpoint cannot be abused as an Oracle, as attempts to query unlisted paths are correctly blocked before database lookups occur.
To successfully exploit CVE-2026-68586, an attacker must satisfy several preconditions. First, the target SiYuan instance must have publishing mode enabled, allowing external readers to access at least some part of the notes database. Second, the attacker must obtain or accurately guess the unique block identifier (defID) and the target document identifier (refTreeID). Since SiYuan's IDs follow a structured, time-based format, these values are occasionally discoverable through metadata leaks, shared links, or brute-force enumeration.
Once the identifiers are acquired, the attacker bypasses the application's front-end interface, which would normally hide the forbidden notes. The attacker sends a crafted POST request directly to the vulnerable /api/ref/getBacklinkDoc or /api/ref/getBackmentionDoc API endpoints. The request body contains the targeted defID and the forbidden refTreeID as parameters, requesting the application to return the rendered context of the backlink.
POST /api/ref/getBacklinkDoc HTTP/1.1
Host: target-notes.local
Content-Type: application/json
Connection: close
{
"defID": "20260721000002-blockid99",
"refTreeID": "20260721000001-docid01",
"keyword": ""
}If the server is running a vulnerable version of SiYuan, the API handles the request without verifying the publication status of docid01. The response contains a JSON payload with the fully rendered HTML DOM of the restricted document. This effectively leaks the content of the private note. Furthermore, because the endpoint only returns data when a relationship exists, the attacker can systematically query different defID values against the target refTreeID to map references between private and public documents, creating a reference-existence oracle.
The security impact of this vulnerability is significant, particularly for organizations or individuals relying on SiYuan to host public-facing documentation while storing sensitive internal intellectual property in the same database. By exploiting this flaw, unauthorized external parties can extract arbitrary documents that were explicitly designated as private or password-protected by the administrator. This completely nullifies the confidentiality guarantees provided by the publish-access controls.
The Common Vulnerability Scoring System (CVSS) v4.0 rating is calculated as 9.2 (Critical), reflecting the ease of remote, unauthenticated exploitation and the potential for complete loss of confidentiality. The vector breakdown highlights that no special user interaction or privileges are required to carry out the attack. Because the application can run in a headless, public-facing configuration, anyone on the internet with network access to the server can execute this exploit silently.
From a data exposure perspective, the risk is compounded by the structure of modern knowledge graphs. Because notes often contain sensitive credentials, personal identifiable information, and API keys, the unauthorized retrieval of entire document trees can lead to broader infrastructure compromise. While the integrity and availability of the system are not directly affected, the breach of confidentiality is total for any document whose ID is successfully targeted.
The primary remediation strategy is to update the SiYuan installation to version 3.7.3 or higher. The patches introduced in this release ensure that both the metadata and content endpoints apply uniform authorization checks against the publishing configuration. Organizations using automated deployment tools should verify that their container images or binary installations have been updated to reflect this version release.
For environments where immediate upgrading is not possible, security teams must implement strict workarounds. Enabling Publish Basic Authentication is highly recommended. By restricting access to the entire publishing directory using strong credentials, administrators can prevent anonymous, unauthorized external actors from interacting with the backlink endpoints. This limits the attack surface to authenticated users only.
Additionally, network-level controls can be deployed to intercept and monitor traffic to the vulnerable paths. Web Application Firewalls (WAFs) should be configured to log and alert on requests directed at /api/ref/getBacklinkDoc and /api/ref/getBackmentionDoc coming from public IP addresses. Organizations can also deploy custom detection signatures to detect repetitive query behavior targeting these endpoints, which may indicate active ID enumeration or brute-force attempts.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
SiYuan siyuan-note | < 3.7.3 | 3.7.3 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-862 (Missing Authorization) |
| Attack Vector | Network (Remote) |
| CVSS v4.0 Score | 9.2 (Critical) |
| CVSS v3.1 Score | 8.6 (High) |
| Exploit Status | Proof-of-Concept Available |
| CISA KEV Status | Not Listed |
| Remediation Status | Patched in v3.7.3 |
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
A path traversal vulnerability (CWE-22) in Contao CMS allows unauthenticated remote attackers to bypass directory boundary restrictions in ImagesController and access files within the project directory.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.