CVE-2026-72794 is an information exposure flaw in SiYuan. In publish mode, the getConf endpoint returned the session cookie signing key to unauthenticated users, who could then forge valid session cookies. The record scores it 8.6, High. Upgrade to SiYuan v3.7.4 or later.
What's affected
The record says SiYuan versions before v3.7.4 are affected. The GitHub advisory lists affected versions as v3.7.2 and earlier, with v3.7.4 as the patched release. Both point to the same fix, so move to v3.7.4 or later.
The advisory explains the exposure in detail. The getConf endpoint is registered with an authentication check only. In publish mode, that check lets through the publish reader token and, when publish authentication is off, the anonymous account. The configuration export endpoint in the same file strips this exact field before it returns settings, so the project already treats it as secret. The masking path used for readers did not.
The weakness class is CWE-522, insufficiently protected credentials.
How to check if you're exposed
Check the version of every SiYuan instance you run, especially ones that publish content to readers.
docker ps --format '{{.Names}} {{.Image}}'
The command above lists container names and image tags, so you can see whether a running SiYuan container is pinned to a version below v3.7.4. For desktop or binary installs, open the About panel in the app. The advisory describes the issue as affecting publish mode, so a private instance that never publishes is not the main concern. Look for any instance that serves pages to readers, with or without a publish password.
What to do now
- Upgrade SiYuan to v3.7.4 or later on every instance that serves published content.
- Treat the cookie signing key as compromised on any instance that was reachable by readers while running a vulnerable version, and rotate it if your version lets you.
- Sign out all sessions after the upgrade, so that cookies forged with the old key stop working.
- Review administrator activity on exposed instances for actions you do not recognise.
- If you cannot upgrade, stop publishing from the instance until you can.
- Keep publish mode instances behind a reverse proxy that you can restrict while you patch.
Why it matters
A signing key is the thing that makes a cookie trustworthy. Anyone who holds it can write a cookie that the server will accept as genuine. That is why exposing it is worse than leaking an ordinary setting. The attacker does not need a password, only a cookie that the key can sign.
The record scores this 8.6 High under CVSS 3.1 and says forged cookies could impersonate users or give administrative access. The GitHub advisory labels it High, and VulnCheck lists it as high with a CVSS 4.0 score of 9.2, so the vendor scale reads higher than the record. Treat it as one of the more serious findings in a publish mode deployment. No source says the flaw has been exploited in the wild, and it is not in the CISA KEV catalog. Rotating the key matters as much as patching, since a key leaked before the fix stays leaked after it.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which SiYuan setups are most exposed?
Instances running in publish mode, since the endpoint was reachable by publish readers and, with publish authentication off, by anonymous users.
Is patching enough?
Patching stops new leaks. If the key was exposed earlier, rotate it and end existing sessions as well.
Sources
Last reviewed: 18 October 2026.
