If you use iTerm2, even "cat readme.txt" isn't safe

iTerm2's SSH integration fails to sufficiently separate terminal output from the control channel, exposing an issue where untrusted text can be interpreted like the conductor protocol.

The core problem is a trust failure. Even without an actual remote SSH session, a malicious file, banner, MOTD, or server response emitting forged DCS 2000p and OSC 135 sequences can trick iTerm2 into believing it's communicating with a real conductor.

Under these conditions, simply running cat readme.txt can cause a fake conductor transcript to be rendered, and iTerm2 will proceed with the following flow on its own.

• Sending getshell
• Sending pythonversion
• Constructing and sending run(...)

An attacker doesn't need to directly inject commands. iTerm2 issues the requests itself, and the malicious output only needs to impersonate the responses.

The exploit also takes advantage of PTY confusion. When there's no actual SSH conductor, a base64-encoded command that iTerm2 writes to the PTY can fall through as plaintext input to the local shell, and if the final chunk is interpreted as an ace/c+aliFIo path, it can lead to execution.

A reproduction PoC is generated with genpoc.py, using the approach of extracting poc.zip and running cat readme.txt. The condition for success is that an executable helper such as ace/c+aliFIo exists in the same directory.

The fix was applied in commit a9e745993c2e2cbb30b884a16617cd5495899f86 on March 31, but at the time of writing it had not yet been included in the stable release. In other words, while the fix has been disclosed, most users remain unpatched, creating a rollout gap that is also flagged as a concern.