CVE-2026-74800

The CVSS 9.1 rating for this stored XSS in SiYuan deserves scrutiny before you treat it as established severity. The vulnerability hinges on an authenticated attacker uploading a malicious HTML asset that, when clicked by a workspace owner, executes with what the advisory calls 'full kernel API access.' That phrase is doing the heavy lifting for the severity score — and it's doing it without proven justification. The core analytical gap: an authenticated attacker already has workspace upload permissions, meaning they can interact with the backend through legitimate API calls. The XSS chain converts server-side upload capability into client-side session hijacking. But what actions does this actually unlock that the attacker couldn't perform through direct API calls using their existing credentials? If SiYuan's kernel API calls are scoped to the authenticated session context, the XSS may be re-packaging existing access in a client-side wrapper rather than expanding the privilege boundary. The CVE narrative asserts 'full kernel API access' as an unverified assumption — historically, when researchers have instrumented similar chains, they've frequently found that broad API claims collapse to session-scoped calls in practice. The missing Content-Disposition and X-Content-Type-Options headers are the technical enabler, but they obscure a deeper architectural question: why does any script executing in the asset origin have kernel API access? This typically happens because legitimate features required it, and the security implications of that power combined with XSS weren't surfaced during review. A Content-Security-Policy nonce-restricting script execution would have severed the XSS-to-kernel path regardless of header absence — the patch addressing headers was the simpler immediate fix, but it left the underlying architectural assumption (browser context equals trusted) unchallenged. For your deployment: verify whether your SiYuan version's kernel API enforces session-scoped access controls that would limit an attacker's XSS-executed calls to their own permissions. If the workspace owner role grants access to other users' data, the compound event becomes confidentiality and integrity impact — but that's a role-configuration question, not a vulnerability default. The CVSS 9.1 reflects current exposure, but if those headers were historically absent, the vulnerability existed longer than temporal metrics imply. Check whether earlier version upgrades gave you false confidence.

Reviewed through automated stages and approved by a human before publication.