Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.7",
  "pubDate": "2026-09-26T14:16:44.843Z",
  "pubdate": "2026-09-26T14:16:44.843Z",
  "executiveSummary": "A vulnerability exists in SiYuan prior to v3.8.4 concerning improper validation of Inter-Process Communication (IPC) messages. The application's Electron main process fails to verify the sender or restrict the target recipients when handling 'siyuan-send-windows' events.\nThis flaw allows a malicious renderer process—potentially under attacker control via a remote kernel—to broadcast arbitrary payloads to all active BrowserWindow instances, regardless of workspace boundaries.\nThe primary risk is a local Denial of Service (DoS) where an attacker can trigger unintended functionality, such as the lockscreen mechanism, across unrelated workspaces.\nWhile there is no observed impact on confidentiality, integrity, or arbitrary code execution, this cross-workspace boundary violation permits unauthorized interaction between isolated user environments within the application context.\nExploitation requires the attacker to influence a renderer process connected to the application, which then acts as a vector to propagate unauthorized commands to the main process, resulting in the execution of restricted functions in sibling windows.",
  "technicalDetails": "The vulnerability originates in the app/electron/main.js file, specifically within the IPC event listener assigned to 'siyuan-send-windows'. The Electron main process acts as the message broker for various renderer processes, but the implementation fails to enforce security boundaries regarding message provenance and destination.\nIn the vulnerable versions, the handler ignores the event.sender object, which is intended to identify the originating renderer process. Instead of validating the source, the handler blindly invokes BrowserWindow.getAllWindows() to retrieve an array of all active windows and iterates through them to forward the received payload.\nThis architecture creates a systemic failure in isolation, as it treats all IPC messages as trusted, regardless of whether they originate from a window within the same workspace or a compromised sibling window. Because the application processes multiple workspaces concurrently via separate windows, this lack of filtering enables an unauthorized cross-boundary interaction.\nAn attacker controlling a remote kernel connected to a renderer process can inject a malicious payload, such as {cmd: 'lockscreenByMode'}. Upon receiving this command, the main process broadcasts the instruction to every BrowserWindow instance. If a window in a separate, legitimate workspace has its lockScreenMode configured to 1, the logic triggers a call to the local lockScreen() function.\nThis allows a remote context to impose a persistent denial of service by repeatedly locking local, unrelated workspaces without the user's consent. The exploitation flow is as follows: 1) An attacker gains control over a renderer process (e.g., via a remote kernel connection); 2) The renderer transmits a command to the 'siyuan-send-windows' IPC channel; 3) The main process, failing to authenticate the sender, blindly propagates the payload to all managed windows; 4) The target windows interpret the broadcasted command, leading to unauthorized state changes or operational disruption.\nThe scope of this vulnerability is limited to the functionality exposed via the IPC handler. Because there is no validation of the cmd parameter against a strict allowlist or an evaluation of the sender's origin, the main process effectively acts as an ambient authority, granting any renderer the power to manipulate the UI state of any other window managed by the Electron main process."
}