A critical vulnerability in iTerm2 allows arbitrary code execution through a simple 'cat' command. The flaw resides in how iTerm2 handles its SSH integration protocol, failing to distinguish between trusted conductor responses and malicious terminal output.

MAD Bugs: Even "cat readme.txt" is not safe

Turning "cat readme.txt" into arbitrary code execution in iTerm2.

In a previous post about AI-discovered bugs in Vim and Emacs, we looked at how seemingly harmless workflows could cross a surprising line into code execution. This time we wanted to push that idea even further: is cat readme.txt safe?

It turns out that it is NOT, if you use iTerm2.

That looks insane until you understand what iTerm2 is trying to do for a legitimate feature, how it uses the PTY, and what happens when terminal output is able to impersonate one side of that feature's protocol.

We'd like to acknowledge OpenAI for partnering with us on this project.

Background: iTerm2's SSH integration

iTerm2 has an SSH integration feature that gives it a richer understanding of remote sessions. To make that work, it does not just "blindly type commands" into a remote shell. Instead, it bootstraps a tiny helper script on the remote side called the conductor.

The rough model is:

iTerm2 launches SSH integration, usually through it2ssh.
iTerm2 sends a remote bootstrap script, the conductor, over the existing SSH session.
That remote script becomes the protocol peer for iTerm2.
iTerm2 and the remote conductor exchange terminal escape sequences to coordinate things like: discovering the login shell, checking for Python, changing directories, uploading files, and running commands.

The important point is that there is no separate network service. The conductor is just a script running inside the remote shell session, and the protocol is carried over normal terminal I/O.

PTY refresher

A terminal used to be a real hardware device. A terminal emulator like iTerm2 is the modern software version of that hardware terminal. It draws the screen, accepts keyboard input, and interprets terminal control sequences.

But the shell and other command-line programs still expect to talk to something that looks like a real terminal device. That is why the OS provides a PTY, or pseudoterminal. A PTY is the software stand-in for the old hardware terminal, and it sits between the terminal emulator and the foreground process.

In a normal SSH session:

iTerm2 writes bytes to the PTY.
The foreground process is ssh.
ssh forwards those bytes to the remote machine.
The remote conductor reads them from its stdin.

So when iTerm2 wants to "send a command to the remote conductor," what it actually does locally is write bytes to the PTY.

The conductor protocol

The SSH integration protocol uses terminal escape sequences as its transport. Two pieces matter here:

DCS 2000p is used to hook the SSH conductor.
OSC 135 is used for pre-framer conductor messages.

At source level, DCS 2000p causes iTerm2 to instantiate a conductor parser. Then the parser accepts OSC 135 messages like begin <id>, command output lines, end <id> <status> r, and unhook.

The core bug

The bug is a trust failure. iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.

That means a malicious file, server response, banner, or MOTD can print a forged DCS 2000p hook and forged OSC 135 replies, and iTerm2 will start acting like it is in the middle of a real SSH integration exchange. That is the exploit primitive.

What the exploit is really doing

The exploit file contains a fake conductor transcript. When the victim runs cat readme.txt, iTerm2 renders the file, but the file contains a fake DCS 2000p line and fake OSC 135 messages. Once the hook is accepted, iTerm2 starts its normal conductor workflow, issuing requests like getshell() and pythonversion().

The PTY confusion that makes exploitation possible

In a legitimate SSH integration session, iTerm2 writes base64-encoded conductor commands to the PTY. In the exploit case, iTerm2 still writes those commands to the PTY, but there is no real SSH conductor. The local shell receives them as plain input instead.

The exploit chooses sshargs so that when iTerm2 base64-encodes the command, the last chunk becomes a valid relative pathname (e.g., ace/c+aliFIo). The local shell then executes this path if it exists.