Missing ownership check on the shared memory object named by the kitty askpass escape code
Description
Missing Authorization (CWE-862) in handle_remote_askpass() (kitty/window.py), in the handler for the askpass escape code, in kitty from 0.25.0 before 0.49.0, which allows a local user other than the one running the terminal to obtain the text typed into a prompt that kitty itself displays, because the handler 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 with no authentication gate. A second local user cannot write to the victim's pseudoterminal, which is owned by the victim and not writable by others, so the attack has a delivery step: the attacker must cause bytes of their choosing to be displayed by the victim's terminal. A file the attacker can write that the victim reads, a shared log the victim tails, or a crafted filename shown by a directory listing all serve.
Where the POSIX shared memory namespace is shared between the two users, the attacker creates an object with permissions that let the victim read and write it, causes the victim's kitty to render a prompt of the attacker's choosing, including a masked password prompt, and reads the typed secret back out of the object afterwards. On a typical Linux system /dev/shm, which backs POSIX shared memory, is a single world-writable tmpfs shared by every user on the machine.
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 at the moment the user answers, rather than through the handle already held, so the object written to need not be the one that was read.
The prompt is drawn by kitty in its own window, in the same style as a legitimate password request from a program the user ran, so the user has no visual indication that the text they type is going to another account.
Vulnerability type (CWE)
- CWE-862: Missing Authorization
Affected versions
kitty from 0.25.0 before 0.49.0. The askpass escape code handler and its use of the shared memory object are first present in v0.25.0; releases before that do not contain the affected code. Every release from v0.25.0 to v0.48.2 inclusive is affected. Default status: unaffected.
Only systems on which the two users share a POSIX shared memory namespace are exposed to the cross-user case. A session confined to its own mount namespace with its own /dev/shm, as in a container, is not. Note that systemd's PrivateTmp= does not provide this: it isolates /tmp and /var/tmp, not /dev/shm.
Score (CVSS 4.0)
Medium (5.6)
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:H/SI:N/SA:N
Privileges required are Low because the attacker needs an ordinary local account on the same machine, with no privilege at all on the victim's account. Attack requirements are Present because the attack depends on conditions outside the attacker's control: the two users must share a shared memory namespace, and the attacker must get bytes displayed by the victim's terminal. Integrity on the vulnerable system is Low because the attacker controls the text kitty renders as its own prompt, including control characters that overwrite the warning line above it. User interaction is Active because the victim has to type an answer into the prompt. The requirement that the attacker's bytes be displayed is counted under attack requirements rather than under user interaction, because the user interaction metric is already carrying the typing; in CVE-2026-95832, where the attacker is whatever writes to the terminal and the only thing the victim does is display the text, that same display is the user interaction and is scored Passive. The confidentiality loss falls on both the terminal and the subsequent system: the secret typed is the user's, not kitty's, and it commonly unlocks something beyond the terminal.
Solution
Upgrade to kitty 0.49.0 or later.
Patch
Commit 32819190, which adds SharedMemory.verify_owner_and_mode() and calls it before the askpass handler reads a prompt definition out of the object, matching the check already performed by the ssh kitten and refactoring that inline check into the shared method. The test requires the mode to be exactly 0600, so an object at 0400 or 0660 is also rejected. The commit further unlinks the name as soon as the object is opened, so nobody else can open it while kitty is using it, and holds that one handle for the reply instead of reopening the object by name when the user answers, which closes the window between the read and the write. It also passes the prompt text, the choice list and the prompt string through sanitize_control_codes(), which removes ESC and so prevents the cursor movement that overwrote the warning line, while retaining newlines. Failures in opening or parsing are now logged and the request dropped.
Credits
- Gabriel Machado Tavares - finder
- Cristian Fernández Cornejo - analyst
- Xoán M. Otero Jorge - analyst
- Secur0 CNA - coordinator
- Kovid Goyal - remediation developer Discovery source: External
Official record: CVE-2026-95835
Related advisories
- CVE-2026-95832 - Critical severity
- CVE-2026-95834 - Medium severity
