The vulnerability arises from the handle_remote_askpass() function in kitty/window.py, which opens a POSIX shared memory object named in an escape code, parses a prompt, and writes the user's response back into the same object without checking that the object is owned by the kitty user or that its permissions exclude other users. Unlike the ssh kitten consumer of the same SharedMemory class, the askpass path lacks this authorization check. An attacker sharing the POSIX shared memory namespace can create an object with permissive access, cause the victim's kitty terminal to render a prompt of the attacker's choosing (including masked password prompts), and subsequently read the victim's typed secret from the shared memory object. The prompt text is also passed to the display without sanitizing control characters, allowing overwriting of kitty's warning line. This results in disclosure of sensitive input to a second local user without requiring elevated privileges.

A local attacker can obtain sensitive information typed by another user into a kitty terminal prompt, including passwords or other secrets, by exploiting the missing authorization checks on shared memory objects. This compromises confidentiality of user input on the affected system. The attacker must be able to cause the victim's terminal to display attacker-controlled bytes and share the POSIX shared memory namespace. No privilege escalation or victim account compromise is required.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, users should avoid running kitty versions from 0.25.0 up to but not including 0.49.0 in multi-user environments where untrusted local users share the POSIX shared memory namespace. Restricting access to the shared memory namespace or avoiding use of the askpass feature may reduce risk.