CVE-2026-80430 in Kitty
Summary
by MITRE • 09/25/2026
Improper Link Resolution Before File Access in the drag source staging path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to create files and directories at paths outside the staging directory, because subdir_data_for_drag() in kitty/dnd.c resolves a descendant of the staged item tree by constructing a path string and opening it with safe_open(path, O_DIRECTORY | O_RDONLY, 0) rather than by walking the tree one component at a time, so a client that declares two entries with the same name, the first a symlink whose target is an arbitrary absolute path and the second a directory, causes mkdirat() to fail with EEXIST, which the code ignores, and causes the subsequent path resolution to follow the symlink and return a directory descriptor outside the staging directory, which is then passed as the dirfd argument to add_payload() and used for every further create operation on that item and its descendants. Entry names are sanitised against path separators and dot components, but symlink targets are not validated. Files are created with O_CREAT | O_WRONLY | O_EXCL at mode 0644, so existing files cannot be overwritten, and directories are created with mkdirat() at mode 0755, so the attacker can create intermediate directories that did not previously exist. This results in the creation of files and directories at any path writable by the user running kitty, provided the symlink target is an existing directory.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified as Improper Link Resolution Before File Access represents a critical flaw within the drag-and-drop protocol implementation of the Kitty terminal emulator, specifically affecting versions from 0.47.0 up to but not including 0.49.0. This security issue stems from an incorrect handling of symbolic links during the file staging process, which is triggered when a user interacts with files dragged into or out of the terminal window. The core technical deficiency lies in how the application resolves paths for items being processed through the drag source stage. Instead of employing a robust method that validates each component of the path against the intended staging directory, the software constructs a full file system path string and attempts to open it using safe_open with flags indicating an intent to access a read-only directory. This approach fails to account for the possibility that intermediate components in the constructed path may be symbolic links pointing outside the allowed sandboxed area.
The operational mechanism of this flaw becomes apparent when a malicious client or application sends drag-and-drop data containing two entries with identical names within the same parent directory. The first entry is defined as a symbolic link where the target points to an arbitrary absolute path on the host file system, potentially leading outside the designated staging directory. The second entry is declared as a standard directory. When Kitty processes these items, it initially attempts to create or access the directory corresponding to the second entry. Because the code ignores errors such as EEXIST if the item already exists in some form, and because the path resolution logic does not strictly enforce that every component of the resolved path remains within the staging root, the system proceeds with the symlinked target. Consequently, subsequent file creation operations are executed relative to this external directory descriptor rather than the intended local staging folder. This effectively bypasses the isolation boundaries designed to prevent arbitrary file writes from terminal-based applications.
The impact of this vulnerability allows an attacker who can control or influence the drag-and-drop input data to create files and directories at any location on the file system that is writable by the user running the Kitty application. While there are certain mitigating factors inherent in the implementation, such as the use of O_CREAT | O_WRONLY | O_EXCL flags for file creation which prevents overwriting existing files, and mode restrictions setting new files to 0644 and directories to 0755, these do not negate the severity of arbitrary directory creation. The ability to create intermediate directories that did not previously exist significantly expands the attack surface, as it allows the attacker to establish a foothold in deeper or more sensitive parts of the file system structure. This is particularly dangerous if the user has write access to configuration files, script locations, or other critical paths where new executables or scripts could be planted for later execution by privileged processes or through social engineering tactics.
From a classification perspective, this vulnerability aligns with CWE-59: Improper Link Resolution Before File Access, also known as a path traversal via symbolic link race condition or improper validation of symlink targets. The failure to validate that the resolved canonical path remains within an expected directory structure is a classic example of insufficient access control relative to file system operations. In terms of offensive security frameworks, this behavior can be mapped to ATT&CK technique T1564: Host File System Discovery or more specifically T1083: File and Directory Discovery if used for reconnaissance, but primarily it facilitates T1059: Command and Scripting Interpreter by enabling the placement of scripts in executable paths. The lack of validation on symlink targets while sanitizing entry names against path separators highlights a partial defense-in-depth strategy that was insufficient to prevent lateral movement within the file system hierarchy.
To mitigate this risk, users should immediately upgrade Kitty to version 0.49.0 or later where these issues have been addressed by implementing stricter path resolution logic. The fix involves ensuring that every component of a dragged item's path is validated against the staging directory root before any file operations are performed. Developers and system administrators should also consider applying principle of least privilege principles, running terminal emulators with restricted permissions when handling untrusted drag-and-drop sources where possible. Additionally, monitoring for unusual creation patterns in user home directories or temporary folders can help detect exploitation attempts of this vulnerability while patches are being deployed across environments.