Hi Nilesh, On Sun, Jun 14, 2026 at 12:50:06AM +0530, Nilesh Patra wrote: > Hi Salvatore, > > I've fixed this in unstable - had a couple of comments and also wanted to > coordinate > an upload for stable. See below.
Thanks! > > On 13/06/26 2:10 pm, Salvatore Bonaccorso wrote: > > Source: kitty > > Version: 0.47.0-3 > > Severity: grave > > Tags: security upstream > > Justification: user security hole > > X-Debbugs-Cc: [email protected], Debian Security Team > > <[email protected]> > > > > Hi, > > > > The following vulnerabilities were published for kitty. > > > > CVE-2026-42850[0]: > > | Kitty is a cross-platform GPU based terminal. In versions prior to > > | 0.47.0, it is possible to inject commands within the subshell > > | through kitty error. A special escape code will make kitty return an > > | error, this error is not escaped and will be correctly echoed back > > | to the terminal with CRLF, as such it will be run by the shell in > > | use. To exploit this bug, the victim must use a netcat or a similar > > | program to connect to the attacker, or else listening for someone to > > | connect. Once this condition is set, an attacker could pwn the > > | computer of the victim using a special kitty's escape code that will > > | run a command in the shell in use. Version 04.7.0 fixes the issue. > > That's a typo (it should be 0.47.0) Yep, this is though under control of the assigning CNA, hopefully they fix it. > > CVE-2026-42851[1]: > > | Kitty is a cross-platform GPU based terminal. In versions prior to > > | 0.47.0, a program able to write bytes to a kitty terminal — a remote > > | SSH peer, a downloaded file viewed with `cat`, a log line, an email > > | body rendered in `less`, an issue body in a TUI, etc. — can cause > > | kitty to execute attacker-supplied Python inside the running kitty > > | process, with the user's full privileges. There is no approval > > | prompt, no remote-control permission requirement, no shell- > > | integration interaction, no clipboard touch, and no editor > > | interaction. Version 0.47.0 fixes the issue. > > Although these 2 are fixed in 0.47.0 itself, they were discovered after 0.47.0 > was released to unstable. Hence I have mentioned them in the upload entries > for 0.47.3-1. The security tracker should probably be adjusted. Thanks, I have updated the tracking information. > > CVE-2026-54055[2]: > > | Kitty is a cross-platform GPU based terminal. In versions prior to > > | 0.47.2, a local privilege escalation vulnerability exists in kitty's > > | file transmission protocol where a child process running in the > > | terminal can write to arbitrary files on the filesystem by > > | exploiting a TOCTOU (Time-of-Check-Time-of-Use) race condition > > | between symlink validation and file creation. The `os.open()` call > > | used to create files does not use `O_NOFOLLOW`, allowing an attacker > > | to create a symlink between the initial stat check and the actual > > | file open, causing the write to follow the symlink to an arbitrary > > | destination. Version 0.47.2 fixes the issue. > > > > ... > > > > CVE-2026-54056[3]: > > | Kitty is a cross-platform GPU based terminal. In versions 0.47.0 and > > | 0.47.1, `kitten dnd` can allow a malicious remote drag-and-drop > > | source to overwrite or truncate arbitrary files writable by the > > | local kitty user. Remote `text/uri-list` drops are staged in a > > | temporary directory, but on case-sensitive filesystems duplicate > > | remote basenames are not de-duplicated. An attacker can first create > > | a staged symlink and then send a same-name regular-file entry. The > > | regular-file write uses `utils.CreateAt()` / > > | `openat(O_RDWR|O_CREAT|O_TRUNC)` without `O_NOFOLLOW`, so it follows > > | the attacker-created symlink and writes outside the staging > > | directory before final overwrite confirmation runs. This appears > > | related in class to the file-transfer symlink advisory, but it is a > > | different bug: it affects `kitten dnd` remote drag-and-drop staging, > > | uses different vulnerable code (`kittens/dnd/drop.go` and > > | `tools/utils/file_at_fd.go`), and reproduces on commit > > | `4aa4a5c0567a92553a8c20a88a4352da637fca5d`, after the file-transfer > > | `O_NOFOLLOW` fix. Version 0.47.2 patches the issue. > > > https://github.com/kovidgoyal/kitty/security/advisories/GHSA-r892-cv7q-fw8x > > Says this is in "Affected versions >= 0.47.0, <= 0.47.1" so I am ignoring > CVE-2026-54056 > for stable release. We should try to assess where this has been introduced, do you have the introducing commit in 0.47.0 for it? In which case we can make sure that we do not have a backport of that introducing commit in earlier versions. > > CVE-2026-54057[4]: > > | Kitty is a cross-platform GPU based terminal. In versions prior to > > | 0.47.3, kitty's OSC 21 (color-control) query reply reflects > > | attacker-controlled bytes, including newlines, into the shell's > > | input without sanitization. Version 0.47.3 fixes the issue. > > I've prepared a stable release update fixing CVE-2026-42850, CVE-2026-42851, > CVE-2026-54055 and CVE-2026-54057. The debdiff is attached with this email. > Please take a look. > > I've also pushed my changes to salsa if this is easier to review > https://salsa.debian.org/debian/kitty/-/tree/debian/trixie-security?ref_type=heads > > I've tested the fixes against the PoCs mentioned in the github advisories, > and could > see exploits working with the current version in trixie and fail with the > version I > prepared -- so that means the fixes should be in order. > > Quick notes: > > - There is no PoC mentioned for CVE-2026-54055, just a vague description, and > hence > I did not test this. But this is a medium severity CVE with a simple fix to > just add > in `O_NOFOLLOW` and this should be good enough. > > - Fix for CVE-2026-42851 is not an exact backport of upstream commit, but > some partial > change along with a fix suggested on the github advisory. The reason is that > the upstream > fix is not easily backportable. But the fix does work as I tested. > > Please let me know if I should proceed ahead with an upload to > trixie-security? Thanks, I have added kitty in dsa-needed for someone to review the debdiff and then see how we proceed. > > If you fix the vulnerabilities please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > > > For further information see: > > > > [0] https://security-tracker.debian.org/tracker/CVE-2026-42850 > > https://www.cve.org/CVERecord?id=CVE-2026-42850 > > [1] https://security-tracker.debian.org/tracker/CVE-2026-42851 > > https://www.cve.org/CVERecord?id=CVE-2026-42851 > > [2] https://security-tracker.debian.org/tracker/CVE-2026-54055 > > https://www.cve.org/CVERecord?id=CVE-2026-54055 > > [3] https://security-tracker.debian.org/tracker/CVE-2026-54056 > > https://www.cve.org/CVERecord?id=CVE-2026-54056 > > [4] https://security-tracker.debian.org/tracker/CVE-2026-54057 > > https://www.cve.org/CVERecord?id=CVE-2026-54057 > > If you could, please, in future reports also link up github advisories. That > is extremely > helpful, as I don't have to open mitre multiple times, click on github links, > scan through > the commits, dig through it locally and then get confused with the CVE number > eventually and > have to backtrack :) Well usually I do more detailed reports including fixing references. In his case we got a batch of CVEs for kitty and was better to get that early to you. But usually you would see single bug reports for each issue including more dtailed information. Unfortunately due to recent floods of AI assisted findings with CVE assignments make it necessary but make substantial batched bugreports for CVEs and bit less detailed bugreports. Regards, Salvatore
