Patch Forecast
Yellow warning
Plan into this sprint.

GHSA-xp3q-r38w-vgqm

SiYuan: The publish filter for local storage returns the administrator's entire storage map with only three keys sanitized

Risk score
45/100
CVSS
5.8 v3.1
Published
23 Oct 2026

Open in the live forecast Today's forecast

What to know

What it is
That advisory concerned the administrator's live UI layout, and commit 63c7d5474 resolved it by removing FilterUILayoutByPublishIgnore and nulling Conf.UILayout for readers. That fix is correct and complete for the live layout. This report concerns a different endpoint, a different filter function and a different stor…
Affected
github.com/siyuan-note/siyuan/kernel (go) < 0.0.0-20260729005258-4daee87d4152
Fix
Upgrade github.com/siyuan-note/siyuan/kernel to 0.0.0-20260729005258-4daee87d4152 or later.
Exploitation
Public proof of concept

Story map

Story map: github.com/siyuan-note/siyuan/kernelTHE FLAWSTHE FIXGHSA-xp3q-r38w-vgqmSiYuan: The publish filter forlocal storage returns theadministrator's entire…CVSS 5.8CVE-2026-69085SiYuan: Unauthenticated SQLinjection in searchDocs viaunescaped keyword (publish…CVSS 10.0 · EPSS 1%CVE-2026-73054SiYuan: A parser differentialbetween the WebSocketkeepalive exemption and the…CVSS 7.5 · EPSS 1%GHSA-9cqf-hhrq-7v45SiYuan:getAttributeViewSearchTargetreturns database row content…CVSS 8.6Upgrade…3.7.3 · 3.7.4or later on your release lineWho is exposedgithub.com/siyuan-note/siyuan/kernel (go) <0.0.0-20260721043339-eef10568384eRED · ACT TODAYgithub.com/siyuan-note/siyuan/ke…SiYuan before v3.7.3 contains aSQL injection vulnerability in the/api/filetree/searchDocsendpoint, where thecaller-supplied keywordparameter is concatenateddirectly into SQL statements…Where it standsPublic proof of conceptCONNECTS TOSame weaknessIncorrect authorisation (CWE-863)336 other warnings in 30 days →
Story map: the flaws, the fix, how it unfolded and what it connects to. Boxes link to the record or article.

At a glance

github.com/siyuan-note/siyuan/kernel: Red, act today. SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish …

The flaws

  • GHSA-xp3q-r38w-vgqm: SiYuan: The publish filter for local storage returns the administrator's entire storage map with only three keys sanitized (CVSS 5.8)
  • CVE-2026-69085: SiYuan: Unauthenticated SQL injection in searchDocs via unescaped keyword (publish mode): cross-notebook read/write with statement stacking (CVSS 10.0 · EPSS 1%)
  • CVE-2026-73054: SiYuan: A parser differential between the WebSocket keepalive exemption and the session quarantine allows unauthenticated access to the broadcast event stream (CVSS 7.5 · EPSS 1%)
  • GHSA-9cqf-hhrq-7v45: 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 (CVSS 8.6)

The fix

Upgrade github.com/siyuan-note/siyuan/kernel: 3.7.3 · 3.7.4 or later on your release line

Who is exposed: github.com/siyuan-note/siyuan/kernel (go) < 0.0.0-20260721043339-eef10568384e

Where it stands

  • Public proof of concept

Connects to

Why it is Yellow

  • CVSS 5.8 medium
  • Public exploit or proof of concept referenced
  • On your watchlist: Go

Affected packages

PackageEcosystemVulnerableFixed in
github.com/siyuan-note/siyuan/kernelgo< 0.0.0-20260729005258-4daee87d41520.0.0-20260729005258-4daee87d4152

References

Original description

### Relationship to GHSA-hgfg-j9pg-43xw That advisory concerned the administrator's live UI layout, and commit `63c7d5474` resolved it by removing `FilterUILayoutByPublishIgnore` and nulling `Conf.UILayout` for readers. That fix is correct and complete for the live layout. This report concerns a different endpoint, a different filter function and a different storage backing. `/api/storage/getLocalStorage` reads `data/storage/local.json` rather than `Conf.UILayout`, and its filter `FilterLocalStorageByPublishAccess` was not touched by that commit. The consequence is that the same serialized tab objects the earlier fix withheld continue to be served, from the closed-tab history rather than the live layout. ### Summary Three routes, `/api/storage/getLocalStorage`, `getLocalStorageVal` and `getLocalStorageVals`, are registered with `CheckAuth` only and are reachable by the publish `RoleReader` token and anonymously when `Publish.Auth.Enable` is `false`. All three call `model.GetLocalStorage()` and then, for read-only roles, `FilterLocalStorageByPublishAccess`. That filter begins by assigning the administrator's entire storage map to its return value and then removes three specific fields. Everything else in the map is returned unmodified. A single unauthenticated POST with an empty body returns the administrator's recently closed tabs with their document titles and identifiers, their current search keywords and the paths those searches cover, the expanded private paths in their file tree, and per-document identifiers from several other keys. ### Details **Routes.** `kernel/api/router.go:87-89` on master, the same block on the development branch: ```go ginServer.Handle("POST", "/api/storage/getLocalStorage", model.CheckAuth, getLocalStorage) ginServer.Handle("POST", "/api/storage/getLocalStorageVal", model.CheckAuth, getLocalStorageVal) ginServer.Handle("POST", "/api/storage/getLocalStorageVals", model.CheckAuth, getLocalStorageVals) ``` No `CheckAdminRole`, no `CheckReadonly`. **The filter is an allowlist inverted into a blocklist.** `kernel/model/publish_access.go:911` on master and `:1481` on the development branch, byte-identical on both: ```go func FilterLocalStorageByPublishAccess(publishAccess PublishAccess, localStorage map[string]any) (ret map[string]any) { ret = localStorage // the entire administrator map publishIgnore := GetInvisiblePublishAccess(publishAccess) // clears local-searchkeys["keys"] // clears local-searchasset["k"] and ["keys"] // blanks local-docinfo["id"], only when bt != nil, visible tier only, no password check return } ``` `local.json` holds roughly thirty keys. Three are sanitized. The rest are returned as stored. **What survives.** Taking the client's own list of keys it round-trips through this endpoint (`app/src/protyle/util/compatibility.ts:563`), the notable survivors are: - `local-closed-tabs`. Up to `SIZE_UNDO` entries, each produced by `layoutToJSON(item, tabJSON)` at `app/src/layout/Wnd.ts:779`. This is the same serializer that produced the data in the earlier advisory: tab title, `docIcon`, `rootId`, `notebookId`, `blockId`, `mode`, `action`, and for a Search tab the entire config object. Unfiltered. - `local-searchdata`. The live document-search configuration, including `k` (the search text), `r` (replace text), `hPath`, `idPath` (the paths the search was scoped to) and `types`. Note the filter clears the search *history* array and the *asset*-search keyword, but leaves the document-search keyword itself. The project's own standard is applied to two of the three related fields. - `local-filespaths`. `IFilesPath[]` of `{notebookId, openPaths[]}`, the expanded private notebook and folder paths in the file-tree dock. - `local-fileposition`, `local-outline`, `local-zoom`. Keyed by document or block identifier, so each discloses private document identifiers. - `local-move-path`. `{keys[], k}`, the move-document dialog's path history and last keyword. - `local-recent-docs`, `local-history`, `local-flashcard`, `local-dailynoteid`, `local-layouts`. **The asymmetry is visible in the function signature.** In the same file, `kernel/api/storage.go`: | Handler | Filter | Receives `*gin.Context` | |---|---|---| | `getCriteria` | `FilterCriteriaByPublishAccess(c, ...)` | yes | | `getRecentDocs` | `FilterRecentDocsByPublishAccess(c, ...)` | yes | | `getLocalStorage` / `Val` / `Vals` | `FilterLocalStorageByPublishAccess(publishAccess, data)` | no | The two sibling filters take the request context and can therefore call `CheckPublishAuthCookie` to evaluate the password tier. `FilterLocalStorageByPublishAccess` does not receive the context, so it cannot perform that check at all. The visible-only limitation is fixed in the parameter list rather than in the body. Separately, `local-recent-docs` passes through this endpoint unfiltered, which bypasses the dedicated `FilterRecentDocsByPublishAccess` that guards the same data on `getRecentDocs`. **Note on a prior assessment.** `getLocalStorage` appears on lists of endpoints considered correctly filtered, on the basis that it calls a `Filter*ByPublishAccess` function. That observation is accurate and this report does not contradict it. The filter is called. What it does is assign the whole map and remove three fields. **No persistence side effect.** The in-place mutations the filter performs do not corrupt the administrator's stored state, because `GetLocalStorage` re-reads and unmarshals `storage/local.json` on each call (`kernel/model/storage.go:82`), so the map is per-request. This is noted to pre-empt the concern rather than as part of the finding. ### Proof of Concept Precondition: publish mode enabled (default port 6808), anonymous when `Publish.Auth.Enable` is `false`, otherwise any publish reader account. An administrator who has used the client normally, closing some document tabs and running a search. ``` POST http://127.0.0.1:6808/api/storage/getLocalSt

Last activity 23 Oct 2026. Patch Forecast updates every hour.