GHSA-w7cg-whh7-xp28
HIGHGHSA-w7cg-whh7-xp28 is a high-severity (CVSS 7.1) Cross-site Scripting (XSS) vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-w7cg-whh7-xp28 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan: Stored XSS in Bazaar marketplace via package README event handlers
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w7cg-whh7-xp28.
EPSS Exploitation Probability
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-w7cg-whh7-xp28 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 369,023 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
github.com/siyuan-note/siyuan/kernelReal-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
renderPackageREADME in kernel/bazaar/readme.go renders a Bazaar package README from Markdown to HTML with the lute engine and SetSanitize(true). The lute sanitizer is an event-handler blocklist: allowAttr rejects only attribute names present in a fixed eventAttrs map copied from the w3schools legacy handler list.
That map omits modern event handlers. onpointerover, onpointerdown, onauxclick, onbeforetoggle, onfocusin, onanimationstart, and ontransitionend are not in the list, so the sanitizer passes them through verbatim on any tag.
The frontend assigns the rendered HTML to mdElement.innerHTML in app/src/config/bazaar.ts with no client-side DOMPurify on this path, into a normal element in the main document (no iframe, no sandbox). The kernel sends no Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options header on any response, so an inline handler runs when its event fires.
The README is rendered when an Administrator opens a package in Settings → Marketplace, after the one-time marketplace trust consent. Install is not required.
Result: a third-party Bazaar package author runs JavaScript in the Administrator's authenticated SiYuan origin when the Administrator views and interacts with the package listing, and gains full control of the workspace.
Affected
siyuan-note/siyuan, <= 3.6.5 (latest release, 2026-04-21). Confirmed live-exploitable on the b3log/siyuan:v3.6.5 image; identical code on master HEAD.
Condition: the Administrator has accepted the marketplace trust consent (bazaar.trust, default false) and browses community Bazaar packages. The lute dependency pin is github.com/88250/lute v1.7.7-0.20260419134724-bb68012f231d.
Both the online browse path (getBazaarPackageREADME) and the installed-package path (getInstalledPlugin) reach the same sink.
Root cause
render/sanitizer.go:225-232 (lute): allowAttr(name) returns false only when name exists in the eventAttrs map, an attribute denylist rather than an allowlist.
render/sanitizer.go:235-334 (lute): eventAttrs is the w3schools handler list and contains no pointer, beforetoggle, focusin, animation, or transition handlers.
kernel/bazaar/readme.go:108-118: renderPackageREADME builds the engine with SetSanitize(true) and returns the HTML string to the caller.
kernel/bazaar/readme.go:48-88: GetBazaarPackageREADME renders an untrusted remote package README; kernel/api/bazaar.go exposes it at /api/bazaar/getBazaarPackageREADME (router.go:423, CheckAuth).
app/src/config/bazaar.ts:600 and :609: mdElement.innerHTML = data.preferredReadme / = response.data.html, no DOMPurify, target is a plain div.
Kernel HTTP responses carry no CSP/X-Frame-Options/X-Content-Type-Options header (live-confirmed), so an inline handler is not blocked.
Reproduction
b3log/siyuan:v3.6.5 Docker, default config, access auth code set, marketplace trust accepted.
- Place a package whose README carries a non-blocklisted handler (an online community package produces the identical render at browse time):
mkdir -p workspace/data/plugins/evil-plugin
cat > workspace/data/plugins/evil-plugin/plugin.json <<'JSON'
{"name":"evil-plugin","author":"x","version":"1.0.0","minAppVersion":"3.0.0",
"displayName":{"default":"Evil"},"description":{"default":"poc"},
"readme":{"default":"README.md"},"backends":["all"],"frontends":["all"]}
JSON
printf '<div onpointerover="alert(document.domain)">plugin description</div>\n' \
> workspace/data/plugins/evil-plugin/README.md
- Request the rendered README the way the Marketplace panel does:
curl -s -X POST http://127.0.0.1:6806/api/bazaar/getInstalledPlugin \
-H "Authorization: Token <API-TOKEN>" -H "Content-Type: application/json" \
-d '{"frontend":"all","keyword":""}'
Response data.packages[].preferredReadme contains the handler verbatim:
<div onpointerover="alert(document.domain)">plugin description</div>
A control <img src=x onerror=...> in the same README is returned HTML-escaped and inert.
- In Settings → Marketplace, open the package and move the pointer over its README.
Live-verified: the rendered HTML is assigned to mdElement.innerHTML (no CSP, no sandbox) and the onpointerover handler executes alert(document.domain) in the SiYuan origin on hover. Handlers do not auto-fire on insertion; one pointer/focus/click interaction on the listing triggers them.
Impact
- JavaScript execution in the Administrator's authenticated origin on a marketplace package view plus one hover/click/focus, no install needed.
- Theft of the kernel API token (
conf.api.token), which grants full Administrator API access. - Pivot to
installBazaarPluginand kernel control; the runtime image ships a shell. - A single malicious community package reaches every instance that views its listing.
Credit
Jan Kahmen, turingpoint ([email protected])
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 0.0.0-20260628153353-2d5d72223df4 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
Fix
Update github.com/siyuan-note/siyuan/kernel to 0.0.0-20260628153353-2d5d72223df4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w7cg-whh7-xp28 is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-w7cg-whh7-xp28 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-w7cg-whh7-xp28. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w7cg-whh7-xp28 in your dependencies?
O3 detects GHSA-w7cg-whh7-xp28 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.