SiYuan EUVD-2026-87728

Requires the victim to run the SiYuan Electron desktop app with MULTIPLE workspaces open simultaneously, and at least one renderer must be connected to an attacker-controlled remote kernel (UI:P - the user must initiate/accept that connection). The DoS is only effective against sibling workspace windows whose lockScreenMode is set to 1 (a non-default per-workspace setting), which triggers lockScreen() on the broadcast {cmd: "lockscreenByMode"} message. Limiting factors: victim interaction to connect to a hostile kernel, dependence on the lockScreenMode=1 configuration, availability-only impact, and full recoverability (the user can unlock). No authentication of the IPC sender exists (that IS the vulnerability), but no cross-network unauthenticated exploitation against a default install occurs without the connected-remote-kernel precondition.

This is a genuinely low-priority, high-signal-noise-adjusted issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L) scores 5.3 and correctly reflects an availability-only impact - VA:L/SA:L with zero confidentiality and integrity impact, matching CWE-862 (Missing Authorization) and the description's explicit statement that no confidentiality, integrity, or code-execution impact was observed. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so all exploitation-probability signals are absent or negative. The impact is a limited, recoverable denial of service (repeatedly locking sibling workspace windows), not a durable outage. UI:P plus the requirement that the victim connect a renderer to an attacker-controlled remote kernel meaningfully constrains real-world exploitability. Net: despite a 'medium' numeric score, the real-world risk is low - this is a defense-in-depth IPC isolation fix rather than an urgent threat. Note the supplied source-code 'evidence' is a version-bump diff (3.8.3-beta.1 → 3.8.3) and does NOT contain the actual authorization fix, and the advisory fix version is 3.8.4 - verify the patch commit against the GHSA advisory.

A victim opens a SiYuan workspace whose renderer is connected to a remote kernel the attacker controls, while also having other local workspaces open. The malicious kernel drives that renderer to emit a {cmd: "lockscreenByMode"} payload into the unrestricted 'siyuan-send-windows' IPC channel, which the Electron main process broadcasts to every BrowserWindow; sibling workspace windows configured with lockScreenMode=1 invoke lockScreen(). Repeating the message repeatedly locks unrelated local workspaces, a limited DoS. No public exploit code is known.