CVE-2026-72805: SiYuan: auth bypass exposes private notebook content

GHSA-67x2-mq63-v9vmMEDIUMPoC AVAILABLE
Published September 3, 2026
CISO Take

SiYuan's kernel API has three block endpoints — getBlockBreadcrumb, getRefText, and getBlockTreeInfos — that skip the publish-access check their sibling getBlockInfo correctly enforces, so an anonymous reader (when Publish.Auth.Enable is false) or any publish RoleReader account can pull document titles, ancestor content snippets, and reference text from documents explicitly marked publish-forbidden or password-protected, including encrypted notebooks while unlocked. The blast radius is real for a self-hosted knowledge tool with 2,997 downstream dependents and 40 other CVEs already recorded in the package, but the severity is bounded: CVSS 5.8 confidentiality-only (no integrity or availability impact), EPSS is very low at 0.00237, there's no CISA KEV listing, no public exploit, and no Nuclei scanner template. The only precondition is knowing a block ID, which is trivially obtainable from other reader-reachable endpoints, making this a low-complexity disclosure once an attacker understands the API surface. Patch by upgrading to the fixed kernel build (commit 931ba693375e, released 2026-07-23) — any self-hosted instance running publish mode with anonymous access enabled should be treated as leaking 'forbidden' content until patched. Detection is limited to reviewing kernel access logs for getBlockBreadcrumb/getRefText/getBlockTreeInfos calls against block IDs outside the normal published-document set.

Sources:NVDGitHub AdvisoryEPSSOpenSSFATLAS

What is the risk?

Medium severity (CVSS 5.8, confidentiality-only). Exploitability is low-complexity and requires no privileges beyond an unauthenticated publish session (or a RoleReader token) plus knowledge of a target block ID — a trivial bar since IDs leak from other reader-reachable endpoints. There is no evidence of active exploitation: not in CISA KEV, EPSS is near-floor (0.00237), and no public PoC or Nuclei template exists yet. Exposure is conditional on the operator running SiYuan in publish mode with documents intentionally marked forbidden or password-protected — instances not using publish mode, or using it with all documents intended to be public, are not meaningfully impacted. The package's broader risk posture (OpenSSF Scorecard 5.7/10, 40 prior CVEs, package risk score 32/100) suggests this is one of a recurring pattern of authorization gaps rather than an isolated defect.

How does the attack unfold?

Reconnaissance
Attacker obtains a valid block ID from a normally reader-accessible published document or feed.
AML.T0036
Exploitation
Attacker submits the block ID to getBlockBreadcrumb, getRefText, or getBlockTreeInfos, none of which call the publish-access check that getBlockInfo enforces.
Impact
Attacker receives document titles, ancestor content snippets, and reference text from publish-forbidden, password-protected, or (while unlocked) encrypted notebooks, breaching confidentiality without any authentication.

What systems are affected?

PackageEcosystemVulnerable RangePatched
Jupyter Notebookgo< 0.0.0-20260723163028-931ba693375e0.0.0-20260723163028-931ba693375e
13.5KOpenSSF 5.83.0K dependentsPushed 2d ago79% patched~75d to patchFull package profile →

Do you use Jupyter Notebook? You're affected.

How severe is it?

CVSS 3.1
5.8 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 22% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UINone
SChanged
CLow
INone
ANone

What should I do?

1 step
  1. 1) Upgrade SiYuan kernel to the version containing commit 931ba693375ea9877b2ef74f9bfb632fad5bab3f (>= 0.0.0-20260723163028) — this is the authoritative fix, adding the existing checkBlockPublishAccess call to the three unguarded handlers. 2) Until patched, disable publish mode or set Publish.Auth.Enable to true and rotate/restrict RoleReader credentials to trusted parties only. 3) Audit any publish-forbidden or password-protected documents for signs of prior access via getBlockBreadcrumb, getRefText, or getBlockTreeInfos in kernel logs. 4) After patching, verify the *InBox variants (GetBlockRefTextInBox, BuildBlockBreadcrumbInBox) enforce the same publish boundary for encrypted-notebook reads. 5) No compensating WAF/network control fully mitigates this since it is an application-logic authorization gap; treat patching as the only reliable remediation.

How is it classified?

Auth BypassData LeakagePrivacy ViolationRAGAPIAML.T0036

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 10-Data and data governance
ISO 42001
A.6.2.2-Data provenance and access control for AI-relevant data

Frequently Asked Questions

What is CVE-2026-72805?

SiYuan's kernel API has three block endpoints — getBlockBreadcrumb, getRefText, and getBlockTreeInfos — that skip the publish-access check their sibling getBlockInfo correctly enforces, so an anonymous reader (when Publish.Auth.Enable is false) or any publish RoleReader account can pull document titles, ancestor content snippets, and reference text from documents explicitly marked publish-forbidden or password-protected, including encrypted notebooks while unlocked. The blast radius is real for a self-hosted knowledge tool with 2,997 downstream dependents and 40 other CVEs already recorded in the package, but the severity is bounded: CVSS 5.8 confidentiality-only (no integrity or availability impact), EPSS is very low at 0.00237, there's no CISA KEV listing, no public exploit, and no Nuclei scanner template. The only precondition is knowing a block ID, which is trivially obtainable from other reader-reachable endpoints, making this a low-complexity disclosure once an attacker understands the API surface. Patch by upgrading to the fixed kernel build (commit 931ba693375e, released 2026-07-23) — any self-hosted instance running publish mode with anonymous access enabled should be treated as leaking 'forbidden' content until patched. Detection is limited to reviewing kernel access logs for getBlockBreadcrumb/getRefText/getBlockTreeInfos calls against block IDs outside the normal published-document set.

Is CVE-2026-72805 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-72805, increasing the risk of exploitation.

How to fix CVE-2026-72805?

1) Upgrade SiYuan kernel to the version containing commit 931ba693375ea9877b2ef74f9bfb632fad5bab3f (>= 0.0.0-20260723163028) — this is the authoritative fix, adding the existing checkBlockPublishAccess call to the three unguarded handlers. 2) Until patched, disable publish mode or set Publish.Auth.Enable to true and rotate/restrict RoleReader credentials to trusted parties only. 3) Audit any publish-forbidden or password-protected documents for signs of prior access via getBlockBreadcrumb, getRefText, or getBlockTreeInfos in kernel logs. 4) After patching, verify the *InBox variants (GetBlockRefTextInBox, BuildBlockBreadcrumbInBox) enforce the same publish boundary for encrypted-notebook reads. 5) No compensating WAF/network control fully mitigates this since it is an application-logic authorization gap; treat patching as the only reliable remediation.

What systems are affected by CVE-2026-72805?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines.

What is the CVSS score for CVE-2026-72805?

CVE-2026-72805 has a CVSS v3.1 base score of 5.8 (MEDIUM). The EPSS exploitation probability is 0.30%.

What is the AI security impact?

Affected AI Architectures

RAG pipelines

MITRE ATLAS Techniques

AML.T0036Data from Information Repositories

Compliance Controls Affected

EU AI Act: Article 10
ISO 42001: A.6.2.2

What are the technical details?

Original Advisory

**CVE:** This vulnerability corresponds to [CVE-2026-72805](https://nvd.nist.gov/vuln/detail/CVE-2026-72805). ### Summary Three block endpoints return document content snippets and metadata without any publish-access check, while their sibling `getBlockInfo` which returns comparable data does enforce one. All three are `CheckAuth`-only, so they are reachable by the publish `RoleReader` token and by the anonymous account when `Publish.Auth.Enable` is `false`. An anonymous reader supplying a block ID receives content and metadata belonging to publish-forbidden and password-protected documents. ### Details `getBlockInfo` (`kernel/api/block.go`) gates on the publish boundary: ```go if !checkBlockPublishAccess(c, id, ret) { return } ``` The following siblings in the same file perform no equivalent check: | Endpoint | Returns | Publish check | |---|---|---| | `getBlockInfo` | root/title/path metadata | `checkBlockPublishAccess`: present | | `getBlockBreadcrumb` | `BlockPath.Name` : root document title plus every ancestor block's content snippet | none | | `getRefText` | the block's reference/anchor text (document content) | none | | `getBlockTreeInfos` | root/title/path metadata for arbitrary block IDs | none | `getBlockBreadcrumb` returns the full ancestor chain including each ancestor block's content snippet, and `getRefText` returns block anchor text both are document content, not just metadata. `getBlockTreeInfos` returns root/title/path for any caller-supplied ID set via `model.GetBlockTreeInfosInBox(...)` with no gate. `getBlockBreadcrumb` and `getRefText` additionally accept a client-supplied notebook argument that routes to the `*InBox` variants, so the same unguarded path applies to encrypted-notebook reads while the notebook is unlocked. The correct primitive already exists in the codebase and is used by `getBlockInfo`; these three handlers simply do not call it. ### Proof of Concept Precondition: publish mode enabled (default port 6808); anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. A document `D` is marked publish-forbidden (or password-protected) and contains a block `BLOCK_ID` under a heading with distinctive content. **Control: the gated sibling correctly refuses:** ``` POST http://127.0.0.1:6808/api/block/getBlockInfo {"id":"BLOCK_ID"} ``` Blocked by `checkBlockPublishAccess`. **Disclosure: the ungated siblings return the data anyway:** ``` POST http://127.0.0.1:6808/api/block/getBlockBreadcrumb {"id":"BLOCK_ID"} → ancestor chain including the forbidden document's title and ancestor block content snippets POST http://127.0.0.1:6808/api/block/getRefText {"id":"BLOCK_ID"} → the block's reference/anchor text (content of the forbidden document) POST http://127.0.0.1:6808/api/block/getBlockTreeInfos {"ids":["BLOCK_ID"]} → root ID, title, and path for the forbidden document ``` Verified by code inspection at `origin/master` (`eef10568`): `getBlockInfo` contains the `checkBlockPublishAccess` call; `getBlockBreadcrumb`, `getRefText`, and `getBlockTreeInfos` contain no publish-access, publish-ignore, or readonly-role check in their bodies. ### Impact An anonymous reader (publish mode with auth disabled) or any publish `RoleReader` can read, for documents explicitly excluded from publishing or protected by a publish password: - the document title and full ancestor chain, including ancestor block content snippets (`getBlockBreadcrumb`); - block reference/anchor text, i.e. document content (`getRefText`); - root ID, title, and path metadata for arbitrary block IDs (`getBlockTreeInfos`). Because `getBlockBreadcrumb` and `getRefText` accept a notebook argument routing to the `*InBox` variants, the same disclosure applies to encrypted notebooks while unlocked. Confidentiality-only; the precondition is a block ID, obtainable from other reader-reachable endpoints. ### Suggested fix Call `checkBlockPublishAccess` (as `getBlockInfo` does) in `getBlockBreadcrumb`, `getRefText`, and `getBlockTreeInfos` before returning data for `getBlockTreeInfos`, apply it per ID and drop unauthorized entries. Confirm the `*InBox` variants (`GetBlockRefTextInBox`, `BuildBlockBreadcrumbInBox`) enforce the same boundary so the notebook-argument path is covered.

Exploitation Scenario

An organization runs a public SiYuan instance in publish mode to share a subset of documentation, with Publish.Auth.Enable left at its default (false) for convenience, and marks a handful of documents — e.g., internal incident postmortems or draft compliance notes — as publish-forbidden or password-protected, assuming they are hidden. An anonymous visitor browsing the published feed discovers a block ID belonging to one of the public documents (a normal, permitted read), then reuses that ID pattern or enumerates nearby IDs and submits it to getBlockBreadcrumb, getRefText, and getBlockTreeInfos. Because none of these three endpoints call checkBlockPublishAccess, the visitor receives the forbidden document's title, its full ancestor chain with content snippets, and its reference text — effectively reading confidential notes without ever passing the publish gate the operator believed was protecting them.

Weaknesses (CWE)

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Timeline

Published
September 3, 2026
Last Modified
September 3, 2026
First Seen
September 4, 2026

Related Vulnerabilities