Calif.io details how iTerm2's SSH integration deploys a remote 'conductor' script that communicates bidirectionally with the emulator using DCS 2000p and OSC 135 terminal escape sequences carried over PTY I/O rather than a separate channel. When a text file containing forged sequences is rendered by cat, iTerm2 instantiates its conductor parser and accepts impersonated replies to internally generated queries such as getshell() and pythonversion(), allowing the malicious output to drive subsequent actions including directory changes and command execution (https://blog.calif.io/p/mad-bugs-even-cat-readmetxt-is-not). The prior Calif.io report on AI-discovered vulnerabilities in Vim and Emacs established the same pattern of benign workflows crossing into code execution via crafted text files (https://blog.calif.io/p/ai-discovered-bugs-in-vim-and-emacs).

Primary coverage correctly identifies the trust failure in accepting conductor messages from arbitrary terminal output yet omits explicit linkage to long-standing terminal security literature, including the 2017 NCC Group analysis of escape-sequence attack surfaces across emulators and the 2021 USENIX paper 'Rendered Insecure: New Vulnerabilities in Terminal Emulators' that catalogued similar parser trust assumptions.

iTerm2's own SSH integration documentation confirms the protocol runs entirely in-band over the same PTY used for ordinary shell output, exposing a systemic gap in foundational CLI tooling where decades-old hardware-terminal abstractions have accreted unauthenticated control messages without sandboxing or origin verification (https://iterm2.com/documentation-ssh.html).