CVE-2026-114606 in drawio-desktop
Summary
by MITRE • 10/23/2026
draw.io Desktop is the official Electron build of draw.io. Prior to 31.4.4, draw.io Desktop is vulnerable to arbitrary local-file disclosure through the Electron main process's read-side IPC handlers. The readFile, getFileDrafts, getBkpFile, fileStat, isFileWritable, checkFileExists, and watchFile actions operate on a renderer-chosen filesystem path with no blessed-path (assertWritablePath) authorization. The only gates are validateSender — a URL-prefix origin check — plus, for readFile alone, a content "sniff" and a lexical appBaseDir prefix block. The write-side handlers (saveFile, writeFile, saveDraft, deleteFile) are all protected by assertWritablePath; the read side is not. The result is a read/write authorization asymmetry: any frame executing in the app's file:// origin can read the contents of local files that the same origin is explicitly forbidden to write. This issue is fixed in version 31.4.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in draw.io Desktop prior to version 31.4.4 represents a critical security flaw rooted in improper access control within the Electron framework's inter-process communication architecture. As an official desktop application built on Electron, draw.io relies heavily on IPC handlers to bridge the gap between the renderer processes, which handle user interface and rendering logic, and the main process, which manages system-level resources such as file I/O operations. The core technical flaw lies in the asymmetry of authorization checks applied to these IPC channels. While write-side operations like saving files or deleting drafts are protected by a robust path validation mechanism known as assertWritablePath, the read-side handlers lack equivalent safeguards. This disparity creates a scenario where an attacker can exploit the less restricted read endpoints to access sensitive local file data that would otherwise be inaccessible due to strict write permissions.
The specific technical deficiency involves several IPC actions including readFile, getFileDrafts, getBkpFile, fileStat, isFileWritable, checkFileExists, and watchFile. These handlers accept filesystem paths provided by the renderer process without validating whether those paths fall within an authorized or blessed directory structure. The only security gate applied to these read operations is validateSender, which performs a URL-prefix origin check, ensuring that the request originates from the application's own file:// protocol context. Additionally, for the readFile action specifically, there is a content sniffing mechanism and a lexical prefix block checking against appBaseDir. However, this lexical check is insufficient because it does not prevent path traversal attacks or access to files outside the intended scope if the input manipulation bypasses simple string matching. Consequently, any frame executing within the application's file:// origin can request the contents of arbitrary local files on the host system, provided they know or can guess valid paths.
This vulnerability is classified under CWE-284 Improper Access Control and aligns with MITRE ATT&CK technique T1083 File and Directory Discovery. The operational impact allows for significant information disclosure, enabling an attacker to read sensitive documents, configuration files, or other data stored on the user's local machine that was not intended to be shared by the application. Since draw.io is often used in professional environments where users may store confidential diagrams, contracts, or proprietary designs locally, this exposure poses a severe privacy and security risk. The ability to read arbitrary files can serve as an initial foothold for further attacks, such as credential theft if configuration files containing API keys are accessible, or reconnaissance leading to more targeted exploits against the host system.
The issue stems from a failure to implement consistent access control policies across all IPC handlers within the Electron main process. In secure application design, especially in desktop environments where applications have broad OS-level permissions, it is imperative that read and write operations undergo equivalent scrutiny regarding path validation. The absence of assertWritablePath or an equivalent directory traversal prevention mechanism on the read side represents a fundamental architectural oversight. This asymmetry suggests that developers may have prioritized security for data modification while neglecting equal rigor for data retrieval, underestimating the risk posed by local file disclosure in desktop applications.
To mitigate this vulnerability and prevent similar issues in future versions, it is essential to enforce strict path validation on all IPC handlers that interact with the filesystem, regardless of whether they perform read or write operations. The assertWritablePath function used for write-side actions should be adapted or mirrored for read-side actions to ensure that only files within explicitly allowed directories can be accessed. Additionally, implementing canonicalization checks before processing file paths will help prevent path traversal attacks using sequences like dot-dot-slash. Developers must also consider adopting a whitelist approach where specific, known-safe directories are defined as the sole sources of accessible files, rather than relying on negative filtering or lexical prefix matches which can be circumvented through clever input manipulation. Upgrading to version 31.4.4 resolves this issue by applying these necessary security controls uniformly across all file system interactions within the application.