iTerm2 critical security release

Original Article ↗ Hacker News Discussion ↗

A critical iTerm2 update fixes a bug in its optional SSH integration that had been silently logging terminal input and output to a world‑readable `/tmp/framer.txt` file on remote hosts, potentially exposing sensitive data. Commenters debate how serious the incident is given the feature’s narrow use, but many highlight it alongside earlier iTerm2 issues as evidence of growing complexity and attack surface in feature‑rich terminal emulators. Alternatives such as Ghostty, kitty, wezterm and the built‑in macOS Terminal are weighed against iTerm2’s powerful capabilities, while others emphasize the maintainer’s quick response and the broader challenge of securing open‑source tools maintained largely by a single developer.

Nature of the vulnerability

  • Bug in iTerm2’s SSH integration caused all stdin/stdout of affected SSH sessions to be written to /tmp/framer.txt on the remote host.
  • Trigger conditions (per release notes discussed):
    • Use of the SSH integration (it2ssh or profile set to “SSH” with “SSH Integration” enabled).
    • Remote host with Python ≥ 3.7 in PATH.
  • Logging was gated by a “verbose” flag that was accidentally shipped enabled; code appears to have started as debugging/verbose logging that wasn’t disabled before release.
  • File was world-readable, so any user on the same remote machine could potentially read another user’s recorded session.

Impact and risk assessment

  • Many commenters note the feature is obscure and rarely used, significantly limiting exposure.
  • Several admin-type commenters say they found no /tmp/framer.txt on their servers despite matching the Python condition.
  • Debate on severity:
    • Some argue you should assume compromise of anything typed, including sudo passwords, and at least clean up /tmp and possibly rotate sensitive credentials.
    • Others note SSH keys themselves are not transmitted this way and see no direct vector for gaining new SSH access, only exposure of whatever was visible/typed in the session.

iTerm2 security track record & trust

  • Thread surfaces prior issues: DNS lookups for hovered text, title-escape vulnerabilities, and search-history leakage into prefs.
  • One side: pattern of “unique and serious” bugs, plus feature creep (SSH, tmux, AI integration) makes iTerm2 feel bloated and risky.
  • Other side: across 10+ years and a huge user base, only a handful of serious issues; fixes are fast and transparent; for a largely single‑maintainer FOSS app this is seen as acceptable and even impressive.
  • Several people explicitly continue to trust and donate to the project; others say they’re now “done” and will switch.

Alternatives and feature trade-offs

  • Alternatives discussed: Ghostty, Kitty, WezTerm, Alacritty, Warp, stock Terminal.app, XQuartz/xterm, Windows Terminal, tmux/screen/zellij.
  • Ghostty gets a lot of attention: praised for speed and minimalism, but missing features (search, tabs in quake mode, some font issues) and has already had at least one terminal-escape vuln.
  • Terminal.app is praised for simplicity and lower attack surface, but lacks 24‑bit color and some power features.
  • Many specific iTerm2 features are cited as “must‑have”: tmux control mode, quake-style drop-down, advanced split panes, triggers, graphics, automatic profile switching, copy-on-select, soft-boundary selection, etc.

Process and lessons discussed

  • Suggestions: use config/env flags instead of hardcoded verbose settings, pre-commit/CI checks for debug artifacts, better naming of risky flags, “NOCOMMIT” markers, code review, fuzzing, and OS-level mitigations (e.g., avoiding shared /tmp).
  • Some emphasize that all complex software has bugs; others argue that for terminals (handling sensitive, untrusted text) extra rigor and minimalism are warranted.