kitty EUVD-2026-87239

Requires: (1) the attacker to be a separate local user on the same host as the victim, with no privilege on the victim's account; (2) a POSIX shared-memory namespace shared between the two users (e.g. a shared /dev/shm), so the attacker can create an object the victim can open and both read/write; (3) the ability to cause attacker-chosen bytes - a device control string - to be displayed in the victim's kitty terminal (e.g. victim views a crafted file, log, or command output); (4) the victim running kitty version 0.25.0 up to before 0.49.0; and (5) the victim actually answering the rendered prompt (UI:A) by typing the secret. Limiting factors: hosts where the SHM namespace is not shared between users, single-user workstations, or kitty >= 0.49.0 are not exploitable; the ssh kitten path was never vulnerable because it already verified owner and permissions.

This is a genuine but tightly-bounded local information-disclosure flaw, not a high-severity remote priority. The provided CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:L/VA:N/SC:H, base 5.6) is internally consistent and well-matched to the description: local attack vector, an existing local account (PR:L), an attack requirement (AT:P - the POSIX SHM namespace must actually be shared between the two users), and active victim interaction (UI:A - the victim must type a secret into the prompt). The high confidentiality impact (VC:H) plus subsequent-system confidentiality (SC:H) correctly reflect that a secret crosses a user-isolation boundary. No EPSS score, no CISA KEV listing, and no public exploit are present in the input - exploitation status is 'no public exploit identified at time of analysis'. The multiple stacked preconditions (shared SHM namespace + ability to inject attacker-chosen bytes into the victim's terminal + victim answering the prompt) make opportunistic mass exploitation implausible; this is a targeted, same-host scenario. There are no conflicting signals in the data: the description, the CVSS vector, and the patch diff (which adds an ownership/permission check identical to the one the ssh kitten already had) all agree that this is a local authorization gap. Overall: real and worth patching on multi-user hosts, but low-to-medium operational priority.

On a multi-user Linux host where /dev/shm is shared, a second local user creates a POSIX shared-memory object with permissions allowing the victim to read and write it, then causes attacker-controlled bytes (a device control string) to be rendered in the victim's kitty terminal - for example by getting the victim to view a crafted file or log. The victim's kitty renders an attacker-defined masked password prompt; when the victim types their secret, kitty writes it back into the same named object, and the attacker reads it out. No public exploit code is identified, and the attack requires the attacker to already have a local account and to induce the byte display and a victim answer.