Listen to this Post
CVE-2026-68586 details a serious authorization bypass in the SiYuan note-taking application’s backlink API. The API is functionally separated into list endpoints, which return document references, and content endpoints, which return the actual rendered HTML. The list endpoints (getBacklink, getBacklink2) are designed to apply a publish-access filter to hide forbidden documents. The content endpoints (getBacklinkDoc, getBackmentionDoc) were overlooked and lack this filter entirely. Both content endpoints are only protected by the CheckAuth middleware, making them reachable by any publish RoleReader or anonymous user if authentication is disabled. The root cause is in model/backlink.go, where no publish-access reference is implemented for the Backlink.DOM field. When getBacklinkDoc is called with a defID and a refTreeID, it fetches and renders blocks from the target document without checking its publish status. This means a document marked as publish-forbidden, publish-disabled, or password-protected will still have its content returned. The list siblings demonstrate that the publish boundary was intended to apply to this data, but the content endpoints simply omit the check. An attacker is not restricted to the filtered backlink list; they can directly call getBacklinkDoc with any arbitrary refTreeID. This direct call also functions as a reference-existence oracle, revealing whether the forbidden document references the given block ID. The proof of concept was reproduced locally with SiYuan running in publish mode on port 6808. The administrator marks a target document as publish-forbidden using the setPublishAccess API. The baseline list request to getBacklink2 correctly returns no backlinks to this document. However, the subsequent request to getBacklinkDoc with the same refTreeID and defID returns HTTP 200. The response’s data.backlinks[].dom contains the unique marker from the forbidden document’s body, confirming the leak. The getBackmentionDoc endpoint behaves identically for mention-type references. This vulnerability undermines the administrator’s explicit configuration for document privacy. The attack requires only a valid refTreeID and defID, with defID often being a known public block. Forbidden document IDs are also obtainable from other unprotected CheckAuth-only endpoints. The overall impact is confidentiality-only, providing content disclosure and an oracle, without any modification capability. No admin role, CSRF token, or write permission is necessary for exploitation. The suggested remediation is to apply the same publish-access check to the content endpoints.
DailyCVE Form:
Platform: SiYuan Note
Version: All prior versions
Vulnerability : Missing Auth Filter
Severity: Medium
date: 2026-09-03
Prediction: Within 7 days
What Undercode Say:
Mark target document as publish-forbidden (admin action)
curl -X POST http://127.0.0.1:6806/api/filetree/setPublishAccess \
-H “Authorization: Token
-H “Content-Type: application/json” \
-d ‘{“id”:”REFTREEID”,”visible”:false,”password”:””,”disable”:true}’
Baseline: list endpoint correctly hides the forbidden doc (anonymous on port 6808)
curl -X POST http://127.0.0.1:6808/api/ref/getBacklink2 \
-H “Content-Type: application/json” \
-d ‘{“id”:”DEFID”,”k”:””,”mk”:””}’
Exploit: content endpoint leaks forbidden document’s DOM (anonymous on port 6808)
curl -X POST http://127.0.0.1:6808/api/ref/getBacklinkDoc \
-H “Content-Type: application/json” \
-d ‘{“defID”:”DEFID”,”refTreeID”:”REFTREEID”,”keyword”:””}’
Identical vector for mention-type references
curl -X POST http://127.0.0.1:6808/api/ref/getBackmentionDoc \
-H “Content-Type: application/json” \
-d ‘{“defID”:”DEFID”,”refTreeID”:”REFTREEID”,”keyword”:””}’
Exploit: (Educational Purposes!)
- Obtain a known public block ID (DEFID) from any published document.
- Acquire the target forbidden document’s ID (REFTREEID) via other CheckAuth-only enumeration endpoints.
- Send an unauthenticated POST request to /api/ref/getBacklinkDoc with defID and refTreeID.
- Parse the HTTP 200 response; the data.backlinks[].dom field contains the full rendered HTML of the forbidden document’s referencing blocks, including secret markers.
- To check reference existence, observe the presence or absence of backlink entries in the response JSON.
Protection: from this CVE
Apply the same publish-access filter used in getBacklink/getBacklink2 to getBacklinkDoc and getBackmentionDoc. In each endpoint, iterate over every returned Backlink and validate its source document’s box/path via CheckPathAccessableByPublishIgnore. Additionally, enforce the publish-password cookie check consistent with FilterPathsByPublishAccess. Ensure that any endpoint returning rendered block DOM enforces the identical publish boundary as the corresponding list endpoint.
Impact:
Anonymous readers (or publish RoleReaders) can read the rendered content of publish-forbidden, publish-disabled, or password-protected documents by directly calling content endpoints. This also provides a reference-existence oracle to determine if a forbidden document references a specific public block. The attack requires no admin privileges, CSRF tokens, or write permissions. Confidentiality is breached, though integrity and availability remain unaffected. Encrypted notebooks are not impacted.
🎯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
