CVE-2026-105220 in twinejs
Summary
by MITRE • 10/05/2026
Twine 2 desktop through 2.12.0 contains a cross-site scripting vulnerability in importStories() that executes markup from imported story files in the editor window. Attackers can craft a story file whose script calls the twineElectron openWithScratchFile IPC bridge to write and open a .bat file, executing code as the user.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The Twine 2 desktop application, specifically versions through 2.12.0, suffers from a critical cross-site scripting vulnerability within its importStories function. This flaw arises because the application fails to adequately sanitize or validate markup contained in imported story files before rendering them in the editor window. In standard web contexts, cross-site scripting allows attackers to inject malicious scripts that execute in the victim's browser with the privileges of the trusted site. However, in this desktop environment, the implications are significantly more severe due to the integration between the web-based interface and the underlying operating system via Electron IPC bridges. The vulnerability context is rooted in the trust model assumed by Twine 2, where imported content is treated as safe for display without sufficient scrutiny of its executable components or side effects.
The technical flaw centers on the application's handling of story files during the import process. When a user imports a crafted story file, the malicious markup embedded within it is executed directly in the editor window. This execution environment provides access to internal APIs that are not typically exposed to standard web content. Specifically, an attacker can craft a story file containing script code that invokes the twineElectron openWithScratchFile IPC bridge. This bridge serves as a communication channel between the front-end interface and the back-end Node.js process of the Electron application. By leveraging this bridge, the malicious script gains the ability to interact with the local file system in ways that are normally restricted by browser security policies.
The operational impact of this vulnerability is severe, leading directly to remote code execution on the victim's machine. Once the IPC bridge is invoked through the crafted story file, it allows for the creation and opening of arbitrary files, such as a batch script (.bat) on Windows systems. Because the Twine 2 application runs with the privileges of the currently logged-in user, any commands executed via this mechanism inherit those same permissions. Consequently, an attacker can trick a victim into importing a malicious story file, resulting in the automatic execution of arbitrary code on their system without further interaction or confirmation prompts beyond the initial import action. This effectively bypasses traditional sandboxing measures that might otherwise protect desktop applications from web-based attacks.
From a classification perspective, this vulnerability aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. Furthermore, because it involves executing local files and commands through an application interface, it also relates to CWE-78, Improper Neutralization of Special Elements used in an OS Command. In terms of the MITRE ATT&CK framework, this attack vector corresponds to T1204, User Execution, where a victim is tricked into performing an action that leads to code execution. The use of IPC bridges for file system access also touches upon aspects of privilege escalation and lateral movement if combined with other vulnerabilities in a broader attack chain.
Mitigation strategies should focus on both immediate remediation and long-term architectural improvements. Users are advised to upgrade immediately to Twine 2 version 2.13.0 or later, where this vulnerability has been patched by implementing stricter input validation and sanitization for imported story files. Developers must ensure that all data passed through IPC bridges is rigorously validated against a whitelist of allowed operations and file types. Additionally, the principle of least privilege should be applied to Electron applications; sensitive functions like opening local scripts or executing system commands should require explicit user consent rather than being triggered automatically by content imports. Security testing procedures for desktop applications must include rigorous fuzzing of IPC interfaces and validation of how external data is rendered in web views to prevent similar injection attacks that bridge the gap between web content and native OS capabilities.