GHSA-phhp-9rm9-6gr2
CRITICALGHSA-phhp-9rm9-6gr2 is a critical-severity (CVSS 9) Cross-site Scripting (XSS) vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-phhp-9rm9-6gr2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan: Remote Code Execution in the Electron desktop client via stored XSS in synced table captions
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
A malicious note synced to another user can trigger remote code execution in the SiYuan Electron desktop client. The root cause is that table caption content is stored without safe escaping and later unescaped into rendered HTML, creating a stored XSS sink. Because the desktop renderer runs with nodeIntegration enabled and contextIsolation disabled, attacker-controlled JavaScript executes with access to Node.js APIs. In practice, an attacker can import a crafted note into a synced workspace, wait for the victim to sync, and achieve code execution when the victim opens the note.
Details
The vulnerability exists in the table caption handling path. When a table block is parsed, the caption attribute is saved into the node's IAL properties without proper HTML escaping. Later, during rendering, that value is read back, passed through HTML unescaping, and written directly into the output DOM. This turns an attacker-controlled caption into active HTML inside the rendered note.
I confirmed that a crafted table caption containing encoded HTML such as <img src=x onerror=...> is rendered as a live DOM element instead of inert text. This makes the issue a stored XSS. I also confirmed that the most practical delivery path is not Markdown import, but a crafted .sy.zip note imported into a synced workspace. Once synced to another desktop client, opening the note executes the payload automatically.
In the Electron desktop client, this XSS results in code execution rather than browser-only script execution. The renderer is configured with nodeIntegration: true and contextIsolation: false, so JavaScript running in the note context can call Node.js APIs directly. A payload such as require('child_process').exec('calc') executes successfully, demonstrating code execution on the victim machine in the context of the logged-in user.
PoC
- SiYuan Desktop Client A: attacker
- SiYuan Desktop Client B: victim
- Both clients are configured to use the same sync target
PoC File
I created a malicious .sy.zip note containing a table block with a crafted caption property.
Safe validation payload:
<img src=x onerror=alert('caption-xss')>
RCE validation payload on Windows:
<img src=x onerror=require('child_process').exec('calc')>
Steps to Reproduce
1.On Client A, import the crafted .sy.zip note using:
Import -> SiYuan .sy.zip
2.Confirm the imported note appears in the workspace.
3.Trigger sync on Client A so the malicious note is uploaded to the shared sync target.
4.On Client B, trigger sync so the note is downloaded from the shared sync target.
5.Open the synced note on Client B.
Observed Result
With the safe payload, JavaScript executes automatically when the victim opens the note. With the RCE payload, the Electron renderer executes:
require('child_process').exec('calc')
This launches Calculator on Windows, demonstrating code execution in the victim user's context.
Impact
- Impact Across All Platforms: Stored XSS
- Electron Desktop App: Remote Code Execution
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 0.0.0-20260407035653-2f416e5253f1 |
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-20260407035653-2f416e5253f1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-phhp-9rm9-6gr2 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-phhp-9rm9-6gr2 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-phhp-9rm9-6gr2. 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-phhp-9rm9-6gr2 in your dependencies?
O3 detects GHSA-phhp-9rm9-6gr2 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.