GHSA-6mcf-g667-w3qv: Medium severity go/github.com/siyuan-note/siyuan/kernel vulnerability
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/publishaccess.go:290) drops rows on the hidden/forbidden tier only: go // 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: go if !CheckPathAccessableByPublishIgnore(...) || !(password == "" || CheckPublishAuthCookie(c, passwordID, password)) { row = nil }
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/siyuan-note/siyuan/kernelto a version that resolves this vulnerability.Fixed in 0.0.0-20260723040913-768427f20f13 - Configuration
Fix CVE-2026-72806 by adding the missing publish-password gate (`password == "" || CheckPublishAuthCookie(c, passwordID, password)`) to the drop condition in all three layout branches (Table, Gallery, Kanban) within the affected sibling filters: `FilterBlockAttributeViewKeysByPublishAccess` (line 412), `FilterBlockInfoByPublishAccess` (line 457), and `FilterContentByPublishAccess` (line 474). This ensures the attribute-view/database-view rows are dropped when the user has not supplied the protected document password, mirroring the sibling filters that already check both hidden/forbidden tier and password tier.
Unknown application code (publish attribute-view filtering; functions include FilterBlockAttributeViewKeysByPublishAccess / FilterBlockInfoByPublishAccess / FilterContentByPublishAccess) Publish password check in drop condition = Add `password == "" || CheckPublishAuthCookie(c, passwordID, password)` to the drop condition for Table, Gallery, and Kanban layout branches
Event History
Frequently Asked Questions
Who can access the exposed data?
A publish RoleReader can access it. If Publish.Auth.Enable is false, the anonymous account can also access the affected rows without entering the document password.
What information may be disclosed?
Every database or attribute-view row bound to a password-protected document may be returned, including the primary cell such as the title or ID and all column values.
What conditions are required for exploitation?
The attacker needs access to a published attribute view containing rows bound to a password-protected document. They do not need the document password; the affected filter checks only hidden or forbidden status and omits the password check.
Are deployments with anonymous publishing disabled still exposed?
Yes. Disabling anonymous publishing removes the anonymous path, but publish RoleReader sessions remain affected if they have not entered the password for documents represented in published attribute views.