Even "cat readme.txt" is not safe: iTerm2’s SSH integration can be tricked into running code

What happened

It has been reported that a flaw in iTerm2’s SSH integration allows terminal output to impersonate the remote helper (the “conductor”) that iTerm2 bootstraps inside an SSH session. iTerm2 uses a tiny conductor script and a protocol carried over terminal escape sequences (notably DCS 2000p and OSC 135) to do useful things like detect shells, change directories, and upload files. The trust model collapses when untrusted output can forge those sequences: a malicious file, banner or MOTD can print a crafted transcript and iTerm2 will treat it like a real conductor. The result is, allegedly, arbitrary code execution — yes, even after you run something as innocent as cat readme.txt.

Why it matters

Terminals are weirdly trusted pieces of software. They sit between you and remote shells via a PTY, and most folks treat their output as harmless text. That assumption is exactly what this bug punches through. This isn’t a generic terminal bug — it’s specific to iTerm2’s conductor protocol — but the implications are broad: local files, server responses, or any text you display in iTerm2 could become an attack vector. It’s a gut punch for developers who’ve long treated the terminal as a safe place to peek at files and logs.

What you should do

For now, take the usual sensible steps: don’t display untrusted files in iTerm2, avoid piping unknown output into open terminals, and keep an eye on iTerm2 advisories for a patch. It has been reported that the researchers behind the write-up (Calif) worked with OpenAI on the project; their post has technical details if you want the nitty-gritty. Want a quick workaround? Consider disabling iTerm2’s SSH integration until a fix lands, or use a different terminal for handling untrusted remote sessions — better safe than sorry.

Sources: calif.io, Hacker News