This Security Issue Is Too Funny To Ignore

Key security problems and conclusions (Omarchy + Kitty)

• The video argues the real-world impact comes from a dangerous, custom Kitty configuration on Omarchy, not from broader “volunteer red team” effort.

• A widely exploitable setting was enabled in Kitty:

  • allow remote control = yes

This allows other programs (including those running over SSH) to control Kitty and potentially trigger remote code execution (RCE) via terminal escape sequences.

• The issue was shared on Twitter as an “Omarchy Linux Kitty terminal remote code execution exploit.”

• While the RCE is described as not necessarily a privilege escalation directly, it still allows an attacker to do anything the user can do:

  • run commands / install binaries
  • exfiltrate or delete user data
  • potentially chain with other bugs for escalation (if present)

Why it happened (technical cause)

• Kitty is not the default terminal on Omarchy (it was Ghostty earlier, Alacritty before that), but Omarchy does support Kitty and provides a custom Kitty config.

• The video pinpoints one config line:

  • allow remote control set to yes

• According to Kitty documentation (as quoted in the subtitles):

  • The default is no, which blocks remote control.
  • With yes, remote control requests are always accepted.
  • Kitty documentation also describes other modes such as socket only, which restricts where/how remote control is accepted.

Configuration details discussed

Related setting: listen on

• listen on = <socket>
  • Used for remote control connections via a Unix socket.
  • It applies to all Kitty instances, with some overrides possible.

Mode behavior

• yes
  • accepts requests more broadly (including over tty and socket)
• socket only
  • accepts remote control requests over socket
  • tty requests are denied/unconditionally rejected depending on mode details

The video presents socket only as the safer approach.

“How the exploit works” (high-level)

The video describes a scenario where an untrusted program (local or remote via SSH) can:

1. send text to the terminal that includes escape sequences
2. trigger Kitty’s remote control mechanism
3. cause Kitty to execute attacker-chosen commands under the user account

A proof-of-concept example mentioned:

• printing a file to the terminal (e.g., via cat) could execute something like touch /tmp/pwn when remote control is enabled
• this demonstrates that “just printing data” isn’t safe with insecure terminal remote control

Upstream Kitty security debate (reported vs. fixed)

• The video claims Kitty’s remote control using escape sequences is fundamentally insecure because terminal control sequences can be injected by “innocent” workflows (mail, IM, file viewing, program output, etc.).
• It describes a debate between:
  • the security reporter
  • and the Kitty developer

Developer’s stance (as summarized in subtitles)

• “text in the terminal is never safe anyway”
• remote control risks are part of broader terminal/escape realities (e.g., DOS-type concerns)

Reporter’s stance

• remote control should be safer by design (e.g., prefer socket-based “safe mode”)

• it should not default to permissive escape-based remote control

• The video says the upstream issue was closed, but the “real fix” wasn’t fully resolved upstream in the way the reporter wanted.

• Instead, it implies Omarchy/Kitty config changes were used to mitigate.

Mitigation / what Omarchy changed

• The recommended action for Omarchy users: update.

• The config change is described as moving from:

  • allow remote control = yes

to a safer restriction described as socket only.

• The video states this should reduce exposure, but “guarantee” is not fully promised:

“we shall see”

Related container security point (general best practice)

• Early subtitles discuss a separate broader security misconfiguration:
  • adding users to the docker group is compared to having root-equivalent power (“free ticket to do literally anything”).
• Mentions that Podman is recommended over Docker to avoid this “foot gun” (as described).

Main speakers/sources

• Primary speaker: the video narrator/host (security commentator; no specific name provided in the subtitles)
• Secondary sources referenced:
  • Omarchy (distro + its Kitty config/commit history)
  • Kitty terminal emulator documentation (quoted for allow remote control and listen on)
  • Kitty GitHub (commit history / debate referenced)
  • Twitter post about the Omarchy Linux Kitty RCE exploit
  • A GitHub gist link to the exploit details (mentioned, but not summarized in content beyond “ways to execute it”)