CVE-2026-100641 in SiYuan
Summary
by MITRE • 09/26/2026
SiYuan before v3.8.4 does not HTML-escape stored flashcard block content before interpolating it into the card-manager list markup. Block content returned by /api/riff/getRiffCards is inserted into a card item template in app/src/card/viewCards.ts and assigned to listElement.innerHTML, so content such as <img src=invalid onerror=...> becomes an executable event-handler attribute. Because the SiYuan desktop (Electron) main window is created with nodeIntegration enabled and contextIsolation disabled, an administrator who opens the card manager on a workspace containing attacker-supplied flashcard content (for example introduced through contribution or import) executes the attacker's script in a privileged renderer, which can lead to arbitrary code execution on the host. The affected endpoint remains behind authentication and administrator-role checks; this is an untrusted-content-to-privileged-renderer issue, not an authorization bypass.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in SiYuan versions prior to 3.8.4 represents a critical client-side code injection flaw rooted in improper handling of user-supplied data within the application's flashcard management interface. The core technical deficiency lies in the failure to perform HTML entity encoding on stored content associated with flashcard blocks before this content is interpolated into the card-manager list markup. Specifically, when retrieving flashcards via the /api/riff/getRiffCards endpoint, the returned block content is directly inserted into a card item template within the app/src/card/viewCards.ts module. This data is subsequently assigned to the innerHTML property of a DOM element using standard JavaScript assignment operations. Because no sanitization or escaping mechanisms are applied during this process, any HTML tags present in the stored flashcard content remain unaltered and become part of the rendered document structure.
This lack of input validation allows for the injection of malicious script payloads disguised as valid HTML attributes. For instance, an attacker can embed a malformed image tag with an onerror event handler, such as <img src=invalid onerror=alert(1)>, within a flashcard's content field. When this content is rendered by the browser engine in the renderer process, the invalid source triggers the error event, causing the embedded JavaScript to execute immediately. This mechanism effectively transforms static data storage into an active vector for cross-site scripting attacks, leveraging the application's rendering pipeline against itself rather than exploiting a network protocol or authentication bypass.
The severity of this vulnerability is significantly amplified by the security configuration of the SiYuan desktop environment, which is built on Electron. The main window of the application is instantiated with nodeIntegration enabled and contextIsolation disabled. In standard web applications, cross-site scripting typically results in limited impact such as session hijacking or data theft within the browser's sandboxed environment. However, in this specific configuration, the renderer process has direct access to Node.js APIs and can interact with the operating system file system, network stack, and other native resources. Consequently, when an administrator opens the card manager containing attacker-supplied flashcard content—whether introduced through legitimate contribution workflows or malicious import operations—the injected script executes within a privileged context. This allows for arbitrary code execution on the host machine, granting the attacker full control over the underlying system with the privileges of the running user account.
From a classification perspective, this vulnerability aligns closely with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. More specifically, it falls under the subcategory of stored cross-site scripting where malicious content is saved on the target server and later served to users. In terms of offensive security frameworks, this attack vector maps directly to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, with a specific focus on JavaScript execution within desktop environments. It also reflects CWE-829, which addresses Inclusion of Functionality from Untrusted Control Sphere, as the application trusts content that has not been adequately validated for safe rendering in a privileged context.
The operational impact is severe because it requires no authentication bypass or privilege escalation to exploit; rather, it relies on social engineering or supply chain compromise to introduce malicious flashcards into a workspace. Once an administrator with sufficient privileges views the compromised card manager, the payload executes automatically without further user interaction beyond opening the view. This creates a high-risk scenario where trusted administrative actions become vectors for system compromise. The distinction that this is not an authorization bypass but rather an untrusted-content-to-privileged-renderer issue highlights that even properly authenticated and authorized users are vulnerable if they consume tainted data, emphasizing the importance of secure coding practices in desktop application development regardless of access controls.
Mitigation strategies must focus on implementing strict output encoding for all dynamic content rendered into HTML structures. Developers should utilize DOMPurify or similar sanitization libraries to strip dangerous tags and attributes before insertion into the DOM. Alternatively, using textContent instead of innerHTML where appropriate can prevent script execution entirely by treating input as plain text rather than markup. Furthermore, adhering to modern Electron security best practices is essential; this includes enabling contextIsolation and disabling nodeIntegration in renderer processes unless absolutely necessary for specific functionality that cannot be achieved through secure IPC channels. By isolating the rendering environment from Node.js capabilities, even if a script injection occurs, its ability to execute arbitrary code on the host system would be neutralized, thereby containing the blast radius of such vulnerabilities within standard web security boundaries rather than allowing full system compromise.