CVE-2026-100634 in SiYuan
Summary
by MITRE • 09/26/2026
SiYuan before v3.8.4 does not validate the sender or restrict recipients in the 'siyuan-send-windows' IPC handler of the Electron main process (app/electron/main.js). The handler ignores event.sender and forwards any received payload to every BrowserWindow returned by BrowserWindow.getAllWindows(), including windows belonging to other opened workspaces. A renderer connected to an attacker-controlled remote kernel can therefore send {cmd: "lockscreenByMode"} and have it delivered across the workspace boundary; a sibling workspace window whose lockScreenMode is set to 1 invokes lockScreen(). Repeated messages allow the remote workspace to repeatedly lock unrelated local workspace windows, causing a limited denial of service. No confidentiality, integrity, or code-execution impact was observed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in SiYuan versions prior to v3.8.4 represents a critical failure in inter-process communication security within the Electron-based application architecture. Specifically, the flaw resides in the IPC handler named siyuan-send-windows located in the main process file app/electron/main.js. In secure software design, especially for applications managing sensitive user data like note-taking platforms, strict validation of message origins and recipients is paramount to prevent cross-context attacks. This implementation fails to validate the sender identity or restrict the destination windows based on workspace boundaries. Consequently, any renderer process that establishes a connection with an attacker-controlled remote kernel can inject arbitrary commands into this handler without authentication checks regarding who initiated the request or which specific window should receive it.
The technical mechanism of exploitation relies on the improper handling of event.sender and the indiscriminate forwarding of payloads to all available BrowserWindow instances retrieved via BrowserWindow.getAllWindows(). In a multi-workspace environment, SiYuan maintains separate contexts for different workspaces to ensure isolation of data and state. However, because the IPC handler ignores these boundaries, it treats all open windows as part of a single broadcast domain regardless of their workspace affiliation. This architectural oversight allows an attacker operating within one workspace context to send commands that are propagated to windows belonging entirely unrelated local workspaces. The lack of origin validation means there is no mechanism to distinguish between legitimate internal messages and malicious injections from external or compromised sources, effectively bypassing the intended security perimeter defined by workspace isolation.
The operational impact of this vulnerability centers on a limited denial of service condition rather than traditional confidentiality breaches or arbitrary code execution. By sending a payload with the command lockscreenByMode set to 1, an attacker can trigger the lockScreen() function in sibling workspace windows that have their lockScreenMode configuration enabled. Since there are no rate limits or validation checks on these IPC messages, an attacker can repeatedly send this command at high frequency. This results in the continuous and rapid locking of unrelated local workspace windows, effectively rendering them unusable for legitimate users. While the attack does not expose private notes or allow remote code execution, it disrupts productivity by forcing repeated user interactions to unlock the interface, creating a persistent nuisance that degrades system availability and user experience.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as the application fails to properly restrict access to functionality based on identity or context. It also relates to CWE-749 Exposure of Sensitive Information to an Unauthorized Actor in the broader sense of violating isolation boundaries, although here it manifests as a functional disruption rather than data leakage. In terms of MITRE ATT&CK frameworks, this behavior is consistent with techniques involving command and control channel abuse or resource hijacking for denial of service purposes, specifically leveraging legitimate application features to disrupt operations. The attack vector involves exploiting the IPC mechanism which serves as an internal communication bus, highlighting risks associated with trusting renderer processes without sufficient verification in Electron applications.
Mitigation strategies must focus on implementing strict validation within the main process before forwarding any IPC messages. Developers should verify that event.sender corresponds to a window belonging to the same workspace context as the target recipient windows. Additionally, introducing rate limiting for specific high-impact commands like lockscreenByMode can prevent abuse even if access control is bypassed. Upgrading to version v3.8.4 or later resolves this issue by enforcing proper sender validation and restricting recipients to appropriate scopes. Until an upgrade is performed, administrators should consider network-level restrictions on renderer processes that connect to external kernels to reduce the attack surface available for IPC injection attempts.