"cat readme.txt" is not safe if you use iTerm2

The core problem was that iTerm2's SSH integration trusted a fake conductor protocol embedded in terminal output.

In the normal flow, iTerm2 uploads a conductor script to the remote session and, via the PTY, exchanges escape sequences to coordinate shell detection, Python checks, directory changes, file uploads, and command execution.

However, this implementation failed to verify whether the terminal output actually came from the real remote conductor. As a result, if a malicious file or server response printed the following:

• Impersonating the conductor hook with DCS 2000p
• Mimicking requests/responses with OSC 135 messages

it could drive iTerm2 into its normal SSH integration state machine.

Using this state, an attacker could get iTerm2 to autonomously proceed with conductor actions like getshell() and pythonversion(), even when the user ran nothing more than a seemingly harmless command like cat readme.txt. Afterward, when iTerm2 sends a run(...) payload over the PTY, since there is no real remote conductor, the local shell accepts that base64 string as ordinary input.

The PoC consists of two files.

• readme.txt: a file containing the malicious DCS 2000p / OSC 135 sequences
• ace/c+aliFIo: an executable helper script pointed to by the final payload

The disclosure timeline is as follows.

• March 30: Reported to iTerm2
• March 31: Fix committed as a9e745993c2e2cbb30b884a16617cd5495899f86

At the time of writing, it was noted that the fix had not yet reached a stable release.