GHSA-5fhr-f75j-8wr9: Medium severity go/github.com/siyuan-note/siyuan/kernel vulnerability

Published Sep 3, 2026
·
Updated

CVE: This vulnerability corresponds to CVE-2026-72800.

Summary

POST /api/av/getAttributeViewKeysByID returns a database's full column schema with no publish-access filtering, while its sibling getAttributeViewKeys applies the filter for reader sessions. Two further endpoints, getBlockDefIDsByRefText and getBlockRelevantIDs return workspace-wide block IDs with no publish scoping. 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.

Details

(a) getAttributeViewKeysByID: ungated column-schema disclosure

The entire handler (kernel/api/av.go, router line 548): go ret.Data = model.GetAttributeViewKeysByID(avID, keyIDs...) // no publish gate

With an empty keyIDs, GetAttributeViewKeysByID calls av.ParseAttributeView(avID) and returns every column's av.Key:

| Field | Discloses | |---|---| | Name, Desc | column title and user-authored description | | Options | the full single/multi-select vocabulary and colours (e.g. status labels such as "Fired", "Confidential") | | Template | the column's Sprig template expression — logic and field references | | Relation | the target avID, allowing pivot to another database | | Rollup, NumberFormat, date config | further schema |

Guarded-sibling asymmetry, same file: getAttributeViewKeys (router line 526) runs FilterBlockAttributeViewKeysByPublishAccess(...) when IsReadOnlyRoleContext. getAttributeViewKeysByID applies nothing. A reader who knows an avID — trivially harvested from the data-av-id attribute of any published document embedding a database obtains the schema of any database in the workspace, including those whose host documents are hidden, password-protected, or publish-forbidden. Relation targets allow walking to sibling databases.

(b) Two unscoped block-ID enumeration oracles

Both CheckAuth-only with no publish gate. Neither returns content of its own, but both yield valid block IDs that other endpoints turn into content:

- getBlockDefIDsByRefText (router line 237) → GetBlockDefIDsByRefText(anchor) returns the block IDs, workspace-wide and including private documents, whose reference/anchor text equals a caller-supplied string: a ref-text → ID oracle. - getBlockRelevantIDs (router line 274) → GetBlockRelevantIDsInBox(id, <notebook from request>) returns parent/previous/next block IDs and traverses decrypted encrypted-notebook structure while the notebook is unlocked, a tree-walk oracle.

Verified at origin/master (eef105683): all three handler bodies contain no publish-access, publish-ignore, or readonly-role check; all three routes are registered CheckAuth without CheckAdminRole.

Proof of Concept

Precondition: publish mode enabled (default port 6808); anonymous when Publish.Auth.Enable is false, otherwise any publish reader account. A database exists whose host document is publish-forbidden or password-protected.

(a) Column schema of any database: POST http://127.0.0.1:6808/api/av/getAttributeViewKeysByID {"avID":"<AVID>"} Returns every column's key object names, descriptions, select vocabularies, template expressions, and Relation target avIDs for a database whose host document the reader may not access.

Control: the sibling getAttributeViewKeys with the same avID returns filtered results for the same reader session, confirming the boundary is enforced there and omitted here.

(b) ID oracles: POST http://127.0.0.1:6808/api/block/getBlockDefIDsByRefText {"anchor":"<known ref text>"} → block IDs workspace-wide, including blocks in private documents

POST http://127.0.0.1:6808/api/block/getBlockRelevantIDs {"id":"<BLOCKID>","notebook":"<BOXID>"} → parent/previous/next block IDs; traverses encrypted-notebook structure when unlocked

Impact

An anonymous reader (publish mode with auth disabled) or any publish RoleReader can read the complete column schema of any database in the workspace, including column descriptions, select-option vocabularies (which frequently encode sensitive category labels), template logic, and relation targets that permit pivoting to further databases regardless of whether the host document is hidden, password-protected, or excluded from publishing.

The two enumeration endpoints additionally supply valid block IDs across the publish boundary, including from encrypted notebooks while unlocked. This removes the "attacker must already know a valid ID" precondition from other block-read endpoints, converting ID knowledge into content disclosure. Confidentiality-only.

Note

getAttributeViewKeysByID is a distinct handler from getAttributeView; although column definitions also appear within the latter's response payload, a fix applied to one handler does not remediate the other, and getAttributeViewKeysByID has its own filtered sibling (getAttributeViewKeys) demonstrating the intended treatment.

Suggested fix

- Gate getAttributeViewKeysByID with FilterBlockAttributeViewKeysByPublishAccess, mirroring getAttributeViewKeys. - Scope getBlockDefIDsByRefText and getBlockRelevantIDs to publish-accessible blocks for reader sessions, and ensure the InBox traversal path applies the same check before walking encrypted-notebook structure.

Affected Software

1 affected componentFixes available
go/github.com/siyuan-note/siyuan/kernel<0.0.0-20260724103335-f36331956ae9
0.0.0-20260724103335-f36331956ae9

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/siyuan-note/siyuan/kernel to a version that resolves this vulnerability.

    Fixed in 0.0.0-20260724103335-f36331956ae9
  2. Upgrade

    Upgrade CVE-2026-72800 to a version that resolves this vulnerability.

    Patch CVE-2026-72800
  3. Configuration

    Gate POST /api/av/getAttributeViewKeysByID with the same publish-access control used by the sibling handler getAttributeViewKeys (router line 526). Specifically, run FilterBlockAttributeViewKeysByPublishAccess(...) when IsReadOnlyRoleContext, mirroring getAttributeViewKeys, so schema/keys are filtered to publish-accessible data.

    getAttributeViewKeysByID API handler (kernel/api/av.go, router line 548) publish-access filtering / readonly-role gating = Apply FilterBlockAttributeViewKeysByPublishAccess for reader sessions (mirror getAttributeViewKeys)
  4. Configuration

    Scope getBlockDefIDsByRefText and getBlockRelevantIDs (routes at router lines 237 and 274) to publish-accessible blocks for reader sessions. Ensure the *InBox traversal path applies the same publish-access check before walking encrypted-notebook structure and returning parent/previous/next block IDs.

    Block ID enumeration endpoints (kernel/api/router) publish-access scoping = Scope to publish-accessible blocks for reader sessions and apply checks before encrypted-notebook traversal
  5. Configuration

    Modify getBlockDefIDsByRefText (router line 237) so GetBlockDefIDsByRefText(anchor) does not return workspace-wide block IDs across private/publish-forbidden/password-protected documents. Instead, return only block IDs the caller’s reader session is allowed to access based on publish access.

    getBlockDefIDsByRefText API handler publish scoping = Enforce publish-access filtering for caller session
  6. Configuration

    Modify getBlockRelevantIDs (router line 274) so GetBlockRelevantIDsInBox(id, <notebook from request>) returns only publish-accessible parent/previous/next block IDs and applies publish-access checks before traversing decrypted encrypted-notebook structure for unlocked notebooks.

    getBlockRelevantIDs API handler publish scoping and notebook traversal access checks = Enforce publish-access filtering before returning traversed encrypted-notebook IDs

Event History

Sep 3, 2026
Advisory Published
via GitHub·11:04 PM
Data Sourced
via GitHub·11:04 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Can an unauthenticated remote user access the affected APIs?

Yes, when Publish.Auth.Enable is false: the anonymous account can reach the endpoints. When publish authentication is enabled, a publish RoleReader token is sufficient.

2

Does exploiting this issue require elevated permissions or user interaction?

No. The affected handlers are CheckAuth-only and can be called by a publish reader session; no user interaction is required.

3

What can a publish reader learn through the exposed API responses?

A reader can obtain a database's full column schema, including column names, descriptions, option vocabularies and colours, and templates. The affected block-reference endpoints can also reveal workspace-wide block IDs without publish scoping.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203