SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Note-taking tools that offer a “publish” mode carry a specific promise, whatever an administrator marks as private stays private, no matter which API a reader calls to get there. CVE-2026-68586, a SiYuan vulnerability disclosed in the “getBacklinkDoc” and “getBackmentionDoc” endpoints, shows what happens when that promise holds on one code path and quietly fails on a neighbouring one.
This SiYuan missing authorization vulnerability carries a CWE-862 classification and a CVSS 4.0 score of 9.2 (Critical). SiYuan is an open-source, self-hosted note-taking and personal knowledge management application built around block-level referencing, used by individuals and teams to store notes, documentation, and internal knowledge on their own infrastructure rather than a vendor’s cloud. Its publish feature lets a user expose part of their workspace as a public or password-gated site, which is the mode CVE-2026-68586 affects.
CVE-2026-68586 was discovered by Shirshak Roy, Security Engineer at SECNORA. It is one of eight CVEs identified in SiYuan. Below is a breakdown of the root cause behind this content disclosure vulnerability, its full CVSS scoring, the exploitation path, and the fix shipped in v3.7.3.
SiYuan’s publish mode exposes backlink endpoints in two categories, and that split is where CVE-2026-68586 originates.
A consistent implementation would apply the same publish-access boundary to both categories. If a document is marked publish-forbidden, neither its existence in a reference list nor its rendered content should reach an outside reader. That consistency is exactly what CVE-2026-68586 breaks.
This is where the CVE-2026-68586 authorization bypass takes shape. SiYuan applied the publish-access boundary to one side only:
getBacklinkDoc and getBackmentionDoc are gated by CheckAuth alone. That check passes for any published RoleReader token, and for anonymous requests when Publish.Auth.Enable is set to false. Neither endpoint evaluates whether the specific document being requested is actually permitted for public viewing.
The file “model/backlink.go” contains no reference to the publish-access filter anywhere in it, which is the root cause CVE-2026-68586 traces back to. When a client calls getBacklinkDoc with the parameters defID and refTreeID, the function returns the rendered content of blocks inside refTreeID, the referencing document, with no check against that document’s publish status. A publish-forbidden, publish-disabled, or password-protected document’s content comes back the same way a public one would.
Exploiting CVE-2026-68586 needs no elevated role, no CSRF token, and no administrator access. It requires network reach to the API plus two identifiers: refTreeID, the ID of the forbidden document, and defID, the ID of a block that document references. In practice defID is often already known, since a forbidden document commonly references public content elsewhere in the workspace.
To make this concrete: a request to “/api/ref/getBacklinkDoc” carrying only “defID” and “refTreeID”, with no authentication header and no session cookie, returns a JSON payload whose “backlinks” array holds a “dom” field. That field is the forbidden document’s rendered HTML, exactly as an authorized viewer would see it, unmarked and unfiltered, sitting in the response body of an anonymous, unauthenticated call.
The same endpoint also works as a reference-existence oracle. By calling it with a guessed or known refTreeID, an attacker can determine whether a private, forbidden document references a specific block, independent of reading its content.
Preconditions: Exploiting CVE-2026-68586 requires both refTreeID and defID. defID can often be sourced from other endpoints that share the same missing-filter pattern, including the SQL execution path covered in CVE-2026-69084, which lowers the practical bar for obtaining both values.
Exceptions: Fully encrypted notebooks fall outside the scope of CVE-2026-68586 and remain protected.
CVE-2026-68586 was one of eight related SiYuan advisories from the same disclosure batch, all rooted in the same publish-access gap on different endpoints, including a metadata disclosure issue in getBlockInfo and a matching rendered-DOM disclosure on the getHeading*Transaction endpoints. The lesson across the batch is consistent: a security boundary enforced on one endpoint family and skipped on a related one is not really enforced at all.
SiYuan’s publish mode is commonly used to expose part of a workspace as a lightweight internal wiki or a client-facing knowledge base, without standing up a separate CMS. Teams doing this rely on the publish-forbidden and publish-disabled flags to keep specific documents, drafts, HR notes, incident write-ups, credentials scratch pads, client-specific pricing, out of that public surface while the rest of the workspace stays visible.
CVE-2026-68586 breaks exactly that assumption. An administrator can mark a document forbidden, verify it disappears from every listing and search result, and still have its full content readable by anyone who reaches the two affected endpoints with the right IDs. No login, no invite, no warning in the UI. For an organisation running publish mode against the open internet, that turns a single misjudged assumption, “if it’s not listed, it’s not reachable”, into a live confidentiality gap. The fix requires no configuration change on the operator’s side, only the version upgrade, which makes patching straightforward once the risk is understood.
All SiYuan versions up to and including v3.7.2 are affected by CVE-2026-68586. v3.7.3 resolves the issue. The same release also closed CVE-2026-68584, the related publish-password bypass on the same family of content endpoints.
The patch applies the same publish-access logic already used by the list endpoints to their content-endpoint counterparts. getBacklinkDoc and getBackmentionDoc now filter each backlink by its source document’s path, using CheckPathAccessableByPublishIgnore alongside a publish-password cookie check, matching the boundary already enforced by FilterPathsByPublishAccess on the list side. Any endpoint that returns rendered block DOM now enforces the same publish boundary as its corresponding list endpoint.
CVE-2026-68586 is a reminder that split API architectures, where one endpoint handles discovery and a related endpoint handles delivery, need matching authorization checks on both sides. A filter applied to the list view and skipped on the content view leaves the actual data exposed even when the index looks clean. Anyone running a public-facing SiYuan instance with publish mode enabled should confirm their version and upgrade to v3.7.3 or later.
SECNORA supports organisations with vulnerability assessments and managed detection and response, helping organisations identify and address vulnerabilities before they can be exploited. Talk to our team.
SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Copyright @ 2026 SECNORA®