CVE-2026-72806 is a medium-severity (CVSS 5.8) CWE-862 vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether CVE-2026-72806 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan: Password (protected) tier omitted in the attribute-view/database publish filter: Reader receives rows of protected documents without the password (publish mode)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-72806.
Real-World Exposure
github.com/siyuan-note/siyuan/kernelReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
CVE: This vulnerability corresponds to CVE-2026-72806.
Summary
FilterViewByPublishAccess, the filter renderAttributeView applies for Reader sessions drops rows using only the hidden/forbidden check and never checks the publish password. Its three sibling filters all check both tiers. As a result, a publish RoleReader (or the anonymous account when Publish.Auth.Enable is false) who has not entered a document's password still receives every database/attribute-view row bound to that password-protected document, the primary cell (title/ID) and all column values.
Details
FilterViewByPublishAccess (model/publish_access.go:290) drops rows on the hidden/forbidden tier only:
// Table (line 311), Gallery (348), Kanban (385), all identical:
if !CheckPathAccessableByPublishIgnore(bt.BoxID, bt.Path, publishIgnore) {
row = nil // hidden/forbidden dropped, but password NEVER checked
}
The three sibling filters all check both the hidden/forbidden tier and the password tier (password == "" || CheckPublishAuthCookie(...)):
FilterBlockAttributeViewKeysByPublishAccess(line 412)FilterBlockInfoByPublishAccess(line 457)FilterContentByPublishAccess(line 474)
So the password (protected) tier is enforced everywhere except this AV/database-view filter. Table layout masks nothing; Gallery and Kanban mask only the cover, keeping the card and its non-cover values. Reachable via renderAttributeView, getAttributeViewKeys, and renderSnapshotAttributeView, all CheckAuth-only.
Proof of Concept
Reproduced on a live instance (publish mode on 6808, anonymous Reader, no password cookie), against a password-protected document with a database/AV row.
| Check | Path | Result |
|---|---|---|
| Control | getDoc(secretDoc) | 🔒 placeholder, body withheld password gate works normally |
| Test | renderAttributeView(AV) | row leaked : blockID=…rk7jofz, title secret-db-row |
Differential (disable=true) | same filter | 0 rows : hidden tier correctly enforced |
| Differential (password set) | same filter | 1 row : password tier bypassed |
Same filter, same document, same Reader: the hidden tier drops the row, the password tier leaks it isolating the omission.
Impact
An anonymous/Reader publish user who has not supplied a protected document's password receives all attribute-view/database rows bound to that document titles, block IDs, and column values defeating the publish-password control for database views. Confidentiality-only. The hidden/forbidden tier is unaffected (correctly enforced).
Suggested fix
Add the password check to the drop condition in all three layout branches (Table, Gallery, Kanban), mirroring the sibling filters:
if !CheckPathAccessableByPublishIgnore(...) ||
!(password == "" || CheckPublishAuthCookie(c, passwordID, password)) {
row = nil
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 0.0.0-20260723040913-768427f20f13 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siyuan-note/siyuan/kernel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/siyuan-note/siyuan/kernel to 0.0.0-20260723040913-768427f20f13 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-72806 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-72806 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-72806. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-72806 in your dependencies?
O3 detects CVE-2026-72806 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.