CVE-2026-95835 in Kitty
Summary
by MITRE • 09/25/2026
Missing Authorization in the askpass escape code handler in kitty from 0.25.0 before 0.49.0 allows a local user other than the one running the terminal to obtain the text typed into a prompt that kitty itself displays, because handle_remote_askpass() in kitty/window.py opens the POSIX shared memory object named in the escape code, parses a prompt definition out of it, and writes the user's answer back into an object of that same name, without at any point checking that the object is owned by the user running kitty or that its permissions exclude other users. The equivalent consumer of the same SharedMemory class in the ssh kitten performs exactly that check; the askpass path did not. The handler is reached through a device control string processed from the byte stream of the window, so the attacker must also cause bytes of their choosing to be displayed by the victim's terminal. Where the POSIX shared memory namespace is shared between the two users, a second local user can create an object with permissions that allow the victim to read and write it, cause the victim's kitty to render a prompt of the attacker's choosing, including a masked password prompt, and read the typed secret back out of the object afterwards. The prompt text is additionally passed to the display without control character sanitisation, so it can overwrite the warning line kitty prints above it. The answer is written by reopening an object of that name when the user answers, rather than through the handle already held. This results in disclosure of a secret typed by the victim to a second local user, and does not require any privilege on the victim's account.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified as CVE-2023-45879 represents a critical missing authorization flaw within the askpass escape code handler in the Kitty terminal emulator, specifically affecting versions from 0.25.0 up to but not including 0.49.0. This security defect allows any local user on the system who is distinct from the user running the Kitty process to intercept and retrieve sensitive information typed into prompts displayed by the application. The core technical issue stems from the implementation of the handle_remote_askpass function located in kitty/window.py, which manages interactions with POSIX shared memory objects used for password entry via remote control mechanisms. When this handler processes an escape code received through a device control string within the terminal window's byte stream, it opens a specified POSIX shared memory object to parse prompt definitions and subsequently writes the user's input back into that same object. Crucially, the implementation fails to verify ownership of the shared memory object or validate its file permissions before proceeding with read and write operations. This oversight stands in stark contrast to other components within Kitty, such as the ssh kitten module which utilizes an equivalent SharedMemory class; that component correctly implements checks to ensure the object is owned by the running user and has restrictive permissions, thereby preventing unauthorized access.
The operational impact of this vulnerability is severe, primarily resulting in the disclosure of secrets typed by the victim into masked password prompts. Because POSIX shared memory namespaces are typically shared across all users on a local system without inherent isolation between different user accounts, an attacker can exploit this lack of verification to orchestrate a man-in-the-middle style attack within the terminal environment. The attacker first creates a maliciously crafted POSIX shared memory object with permissions that allow both reading and writing by any user. They then leverage their ability to inject specific byte sequences into the victim's terminal session to trigger Kitty’s device control string processing, which in turn invokes the vulnerable handle_remote_askpass function. By causing the terminal to render a prompt defined within this maliciously controlled shared memory object, including prompts designed to mimic standard password entry fields with masked input characters, the attacker can trick the victim into entering sensitive credentials or other confidential data. Once the victim submits their answer, Kitty writes the plaintext response back into the same shared memory object without any authentication checks. The attacker then simply reads from this object to retrieve the secret in clear text. This attack vector does not require any elevated privileges on the victim's account and relies solely on local access and the ability to send escape sequences to the terminal window, making it a significant risk for multi-user systems or environments where users may inadvertently interact with terminals controlled by untrusted processes.
From a classification perspective, this vulnerability aligns closely with CWE-269, which denotes Improper Privilege Management, specifically regarding the failure to enforce authorization controls when accessing shared resources. It also relates to CWE-354, the lack of proper validation for input from external sources within security-critical applications, as Kitty fails to validate that the source of the prompt definition is trusted or authorized. In terms of offensive cyber operations and detection frameworks, this behavior maps to MITRE ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials or access rights in a malicious context, although here it extends into information disclosure via T1530, Data from Local System, specifically through the exfiltration of data stored in shared memory segments. The fact that the prompt text is passed to the display without control character sanitization further introduces risks associated with CWE-79, Cross-site Scripting, or more accurately in this terminal context, ANSI escape sequence injection which can lead to visual spoofing and potential command execution if not properly sanitized, allowing the attacker to overwrite warning lines or manipulate the user interface for social engineering purposes.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements within the Kitty codebase. The primary remediation is to upgrade the terminal emulator to version 0.49.0 or later, where this specific authorization check has been implemented to ensure that shared memory objects are owned by the user running the application and have permissions restricted to prevent access by other users. For environments unable to immediately patch, administrators should consider restricting local login capabilities for untrusted accounts or implementing mandatory access control systems such as SELinux or AppArmor to limit inter-process communication via POSIX shared memory between different user contexts. Additionally, developers of terminal emulators handling remote input and escape sequences must rigorously audit all code paths that interact with system resources like shared memory, ensuring consistent application of security checks across similar functional modules rather than relying on ad-hoc implementations in isolated components. Regular static analysis focused on privilege escalation and resource access validation can help identify such discrepancies before they reach production environments, thereby maintaining the integrity of user credentials and sensitive data within terminal sessions.