Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-phhp-9rm9-6gr2

CRITICAL

GHSA-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

Also known asCVE-2026-39846GO-2026-5540
Published
Apr 8, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

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

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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/siyuan-note/siyuan/kernelall versions0.0.0-20260407035653-2f416e5253f1

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-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.

  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-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

### 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.
O3 Security · Impact-Aware SCA

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.