The Hidden Danger in Terminal Emulators: How 'cat readme.txt' Became a Code Execution Vector

In the world of software security, there's a particular class of vulnerabilities that emerge not from obvious flaws, but from the complex interactions between legitimate features. The recent discovery by Codex of a bug in iTerm2 that turns the innocent command cat readme.txt into a potential code execution vector is a perfect example of this phenomenon.

The Legitimate Feature That Created the Attack Surface

iTerm2, one of the most popular terminal emulators for macOS, includes an SSH integration feature designed to provide richer functionality for remote sessions. This feature works by bootstrapping a tiny helper script on the remote side called the "conductor." The conductor acts as a protocol peer, allowing iTerm2 to coordinate various operations like discovering the login shell, checking for Python, changing directories, uploading files, and running commands.

What makes this feature particularly interesting from a security perspective is that it doesn't rely on a separate network service. Instead, the conductor is simply a script running inside the remote shell session, and the protocol is carried over normal terminal I/O using terminal escape sequences.

Understanding the PTY Foundation

To grasp why this vulnerability exists, we need to understand the role of the pseudoterminal (PTY) in modern computing. A PTY is the software equivalent of the old hardware terminals—the physical keyboards and screens that were once directly connected to computers. When you use a terminal emulator like iTerm2, it draws the screen, accepts keyboard input, and interprets terminal control sequences, but it still needs to communicate with programs that expect to talk to something that looks like a real terminal device.

The PTY sits between the terminal emulator and the foreground process, acting as an intermediary. In a normal SSH session, iTerm2 writes bytes to the PTY, which are then forwarded by SSH to the remote machine, where the conductor reads them from its standard input.

The Core Vulnerability: Trust Failure

The fundamental issue discovered by Codex is a trust failure. iTerm2 accepts the SSH conductor protocol from terminal output that isn't actually coming from a trusted, real conductor session. This means that untrusted terminal output can impersonate the remote conductor.

In practical terms, a malicious file, server response, banner, or MOTD (message of the day) can print forged terminal escape sequences that iTerm2 interprets as legitimate conductor protocol messages. The exploit primitive is simple: print a fake DCS 2000p hook followed by forged OSC 135 replies, and iTerm2 will start acting like it's in the middle of a real SSH integration exchange.

How the Exploit Works

The malicious file contains a fake conductor transcript. When a victim runs cat readme.txt, iTerm2 renders the file, but the file isn't just text—it contains carefully crafted terminal escape sequences. The process unfolds like this:

1. A fake DCS 2000p line announces a conductor session
2. Fake OSC 135 messages answer iTerm2's requests
3. Once the hook is accepted, iTerm2 starts its normal conductor workflow
4. iTerm2 issues getshell() and pythonversion() commands itself
5. The malicious output impersonates the replies
6. iTerm2 moves to the next step: building and sending a run(...) command

The clever aspect of this exploit is that it doesn't need to inject the initial requests. iTerm2 issues them itself as part of its normal workflow, and the malicious output only needs to impersonate the replies.

The Critical Role of sshargs

The forged DCS 2000p hook contains several fields, including an attacker-controlled sshargs value. This matters because iTerm2 later uses it as command material when constructing the conductor's run ... request. The exploit chooses sshargs so that when iTerm2 base64-encodes the run command, the last 128-byte chunk becomes a specific string.

This string is carefully chosen to be both valid output from the conductor encoding path and a valid relative pathname. When the final chunk arrives at the local shell (which is receiving it as plain input since there's no real SSH conductor), it resolves to a real executable path if that path exists locally.

The PTY Confusion That Enables Exploitation

The exploitation works because of a fundamental confusion in how the PTY handles the data flow. In a legitimate SSH integration session, iTerm2 writes base64-encoded conductor commands to the PTY, and SSH forwards them to the remote conductor. In the exploit case, iTerm2 still writes those commands to the PTY, but there's no real SSH conductor—the local shell receives them as plain input instead.

This creates a situation where the session looks like this when recorded:

• getshell appears as base64
• pythonversion appears as base64
• Then a long base64-encoded run ... payload appears
• The last chunk is the attacker-controlled string

Earlier chunks fail as nonsense commands, but the final chunk works if that path exists locally and is executable.

Reproducing the Vulnerability

The original proof-of-concept can be reproduced using genpoc.py. The process creates two files: an executable helper script and a malicious readme.txt file containing the crafted escape sequences. For the exploit to work, you need to run cat readme.txt from the directory containing the helper script so the final attacker-shaped chunk resolves to a real executable path.

Timeline and Resolution

The vulnerability was reported to iTerm2 on March 30, and the bug was fixed in commit a9e745993c2e2cbb30b884a16617cd5495899f86 on March 31. At the time of writing, the fix had not yet reached stable releases.

Interestingly, when the patch commit landed, the researchers attempted to rebuild the exploit from scratch using the patch alone. The prompts used for that process are documented in prompts.md, and the resulting exploit is genpoc2.py, which works very similarly to the original.

The Broader Implications

This vulnerability highlights a critical security principle: features that involve complex protocol interactions over shared channels can create unexpected attack surfaces. The iTerm2 SSH integration feature is genuinely useful and well-designed for its intended purpose, but the way it uses terminal escape sequences over the same channel as regular terminal output creates a trust boundary that can be exploited.

For users, this serves as a reminder that even seemingly innocuous commands like cat readme.txt can be dangerous if the terminal emulator has features that interpret terminal output in sophisticated ways. For developers, it underscores the importance of carefully considering trust boundaries when designing features that involve protocol exchanges over shared communication channels.

The fact that this vulnerability was discovered by AI-assisted analysis also points to the evolving landscape of security research, where automated tools can help identify subtle interactions that might be missed by traditional manual code review.

The iTerm2 vulnerability discovered by Codex represents a fascinating case study in how legitimate features can create unexpected security implications. By understanding the technical details of how this exploit works, we gain valuable insights into the complex interactions between terminal emulators, pseudoterminals, and the protocols that modern software uses to enhance functionality. As software continues to evolve with increasingly sophisticated features, this kind of careful analysis of feature interactions will become even more critical for maintaining security.