Summary
SiYuan: getAttributeViewSearchTarget returns database row content to anonymous readers with no publish-access check, reopening the class closed one day earlier at the adjacent route
Scope note
This endpoint does not exist in v3.7.3 or on master. It was introduced on the development branch by commit 9b8e8956f on 2026-07-27 and is present on the current development head. No released stable version is affected.
/api/av/getAttributeViewSearchTarget is registered with CheckAuth only and performs no authorization of any kind. Given a database identifier and a keyword, it searches that database's rows and returns matching content, regardless of whether the caller may see the database, the rows, or the notebook holding them.
Commit 64c26e74b on 2026-07-26 closed a reader-reachable gap on getAttributeViewFieldViews by adding CheckReadonly at router line 536. 9b8e8956f, the following day, registered this endpoint at line 535 without it. The new route returns more than the one that was just closed: row content rather than field-visibility metadata.
Details
Route. kernel/api/router.go:535 on the development branch:
ginServer.Handle("POST", "/api/av/getAttributeViewSearchTarget", model.CheckAuth, getAttributeViewSearchTarget)
No CheckReadonly, no CheckAdminRole.
Handler. kernel/api/av.go parses its arguments and calls model.GetAttributeViewSearchTarget(id, keywords). IsReadOnlyRoleContext, publishAccess and any encrypted-notebook check are all absent. The sink is kernel/model/attribute_view_render.go:69.
The adjacent routes make the omission stark. Lines 533 to 541 all handle the same data class:
| Line | Route | Guard |
|---|---|---|
| 534 | getAttributeViewKeys |
CheckAuth, filters in-body for readers |
| 535 | getAttributeViewSearchTarget |
CheckAuth, nothing |
| 536 | getAttributeViewFieldViews |
CheckAuth, CheckReadonly |
| 540 | searchAttributeView |
CheckAuth, CheckReadonly |
| 541 | getAttributeView |
CheckAuth, CheckReadonly |
The guard at 536 is the one added by 64c26e74b. The new route sits directly above it without one.
Why this is not bounded by identifier guessing. The closest functional sibling, renderAttributeView, applies two distinct reader protections:
- A containing-document gate,
CheckAttributeViewBlockAccessableByPublishAccess, which is the full gate includingCheckPublishAuthCookie. - Per-item filtering,
FilterAttributeViewByPublishAccess, using theitemAccessandattributeAccessmaps. This strips rows bound to restricted blocks out of views the reader is otherwise entitled to see.
The second layer is what makes this exploitable without guesswork. A reader takes a database block identifier from the published DOM of a page they are allowed to view, then queries this endpoint against that same database and receives precisely the rows renderAttributeView removed from the view they were served. GetAttributeViewSearchTarget reaches the same internal render function; it simply bypasses the API-layer gate.
Two aggravating properties.
getAttributeViewSearchMatches runs strings.Contains across every value of every key, and the response carries MatchedKeyID alongside the title. That is a substring oracle over every column, so a caller can test for content without needing to retrieve it wholesale.
The path also branches on IsEncryptedBox(tree.Box) into ParseAttributeViewInBox, so it reads encrypted notebooks while they are unlocked. isEncryptedNotebookDeniedForPublish appears seventeen times across the block, ref, outline, search and filetree paths, and does not appear in av.go at all.
Extraction is iterative. Each request returns a single row. Systematic recovery of a database therefore requires many requests rather than one bulk response. There is no rate limiting on the path, and the substring oracle narrows the search considerably, but I mention it so the effort is not overstated.
Proof of Concept
Precondition: a development-branch build, publish mode enabled (default port 6808), anonymous when Publish.Auth.Enable is false. A published page embedding a database whose view contains rows bound to blocks the reader cannot access.
Step 1, take the database block identifier from the published page's DOM. It is present in the served markup.
Step 2, confirm what the reader is supposed to see:
POST http://127.0.0.1:6808/api/av/renderAttributeView
{"id":"<database block id>"}
→ 200, rows bound to restricted blocks are absent
Step 3, retrieve them anyway:
POST http://127.0.0.1:6808/api/av/getAttributeViewSearchTarget
{"id":"<same database block id>","keywords":"<term>"}
→ 200, matching rows including those step 2 withheld,
with MatchedKeyID identifying the column that matched
The differential between steps 2 and 3, on one session against one database, is the finding.
Impact
An anonymous reader in publish mode, or any publish RoleReader, reads the content of database rows that the publish filters deliberately withhold, including rows in documents that are hidden, password-protected or forbidden, and rows in encrypted notebooks while those notebooks are unlocked. The database identifier required is published in the DOM of pages the reader is entitled to view, so no enumeration or guessing is involved. The substring matching across all columns lets a caller confirm specific content without retrieving whole rows.
Confidentiality only, with no integrity or availability impact.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
GHSA-9CQF-HHRQ-7V45 has a CVSS score of 8.6 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260812083335-251596fc0de2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Add CheckReadonly at router line 535, matching lines 536, 540 and 541. If read-only roles are meant to use this endpoint, apply CheckAttributeViewBlockAccessableByPublishAccess and FilterAttributeViewByPublishAccess inside the handler as renderAttributeView does, and add the isEncryptedNotebookDeniedForPublish check that the block, ref, outline, search and filetree paths already carry.
More generally, the attribute-view routes now split between middleware-gated and in-body-gated, and a new route defaults to neither. A registration-time convention, where any new /api/av/ route is CheckReadonly unless it deliberately implements in-body filtering, would prevent this recurring.
Frequently Asked Questions
- What is GHSA-9CQF-HHRQ-7V45? GHSA-9CQF-HHRQ-7V45 is a high-severity missing authorization vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions >= 0.0.0-20260726161145-9b8e8956f997, < 0.0.0-20260812083335-251596fc0de2. It is fixed in 0.0.0-20260812083335-251596fc0de2. The application does not perform an authorization check before performing a sensitive operation.
- How severe is GHSA-9CQF-HHRQ-7V45? GHSA-9CQF-HHRQ-7V45 has a CVSS score of 8.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/siyuan-note/siyuan/kernel are affected by GHSA-9CQF-HHRQ-7V45? github.com/siyuan-note/siyuan/kernel (go) versions >= 0.0.0-20260726161145-9b8e8956f997, < 0.0.0-20260812083335-251596fc0de2 is affected.
- Is there a fix for GHSA-9CQF-HHRQ-7V45? Yes. GHSA-9CQF-HHRQ-7V45 is fixed in 0.0.0-20260812083335-251596fc0de2. Upgrade to this version or later.
- Is GHSA-9CQF-HHRQ-7V45 exploitable, and should I be worried? Whether GHSA-9CQF-HHRQ-7V45 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-9CQF-HHRQ-7V45 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-9CQF-HHRQ-7V45? Upgrade
github.com/siyuan-note/siyuan/kernelto 0.0.0-20260812083335-251596fc0de2 or later.