iTerm2 flaw turns terminal text into code execution through SSH integration escape sequences

A newly disclosed iTerm2 vulnerability shows that even viewing attacker-controlled terminal output can lead to local code execution under the right conditions. Security researchers at Calif, working with OpenAI, say the bug lets untrusted text impersonate iTerm2’s SSH integration protocol and steer the terminal emulator into writing executable input back into the local shell.

The finding matters because the trigger can look harmless. Calif says a victim could hit the vulnerable path simply by displaying a malicious text file with a command like cat readme.txt, or by rendering hostile output from a server banner, response, or message of the day. The text is not just text. It contains terminal escape sequences that iTerm2 wrongly treats as trusted conductor traffic.

At disclosure time, Calif said the bug had been fixed in source on March 31, 2026, but had not yet reached stable releases. Since then, iTerm2 has published stable version 3.6.10, built on April 20, 2026, with a security note that says it hardens SSH integration against in-band signaling abuse in the conductor handshake and shutdown path.

How the bug works

Calif explains that iTerm2’s SSH integration uses a helper script called the conductor on the remote side of an SSH session. Instead of using a separate service, the feature sends protocol messages over ordinary terminal input and output through the PTY. Two escape-sequence families matter here: DCS 2000p, which hooks the conductor, and OSC 135, which carries conductor messages.

The core flaw is a trust failure. Calif says iTerm2 accepts that conductor protocol from terminal output even when the output is not actually coming from a legitimate remote conductor session. That means a malicious file or server response can forge the same escape sequences and make iTerm2 behave as if a trusted SSH integration exchange is already underway.

Once iTerm2 accepts the fake hook, it starts its normal conductor workflow on its own. Calif says the malicious text only needs to impersonate the replies. That pushes iTerm2 down a fallback path where it constructs a run(...) command using attacker-controlled sshargs, base64-encodes the payload, and writes it to the PTY. In a real SSH integration session, those bytes would travel to the remote conductor. In the exploit case, the local shell receives them as input.

Why the exploit can become code execution

The exploit relies on a confusion between the terminal emulator and the process attached to the PTY. Calif says the attacker chooses sshargs so the final 128-byte encoded chunk becomes ace/c+aliFIo, which is both valid output from the conductor path and a valid relative pathname. If an executable exists at that path in the current working directory, the local shell can end up running it.

That means the bug does not automatically execute arbitrary code from nowhere. Calif’s proof of concept creates both pieces: a malicious readme.txt containing forged escape sequences and an executable helper at ace/c+aliFIo. Running cat readme.txt from the directory that also contains that helper is what turns the protocol confusion into actual local execution.

This detail matters for defenders because it narrows the exact exploitation path without making the issue trivial. The vulnerability still allows attacker-controlled terminal output to drive iTerm2 into unsafe behavior, and Calif’s write-up shows the primitive is real enough to weaponize when the local path and file layout cooperate.

Patch status and affected versions

Calif’s disclosure timeline says the bug was reported to iTerm2 on March 30, 2026 and fixed in source the next day in commit a9e745993c2e2cbb30b884a16617cd5495899f86. The researchers also said stable releases still lagged behind at the time they published their write-up on April 17.

iTerm2’s official downloads page now lists version 3.6.10 as the recommended stable build, built on April 20, 2026. The changelog says this release hardens SSH integration against in-band signaling abuse in the conductor handshake and it2ssh shutdown sequence. That language aligns closely with Calif’s disclosed bug class.

Based on those two sources together, stable releases up to 3.6.9 were exposed, while 3.6.10 appears to be the first stable version carrying the fix. Calif’s post and iTerm2’s release notes support that conclusion.

At a glance

Item	Detail
Product	iTerm2
Vulnerable feature	SSH integration
Trigger	Rendering attacker-controlled terminal output
Protocol pieces involved	DCS 2000p and OSC 135
Practical example	cat readme.txt on a malicious file
Fixed in source	March 31, 2026
Fixed in stable release	iTerm2 3.6.10

Supported by Calif’s disclosure and iTerm2’s release notes.

What users should do now

iTerm2 users should upgrade to version 3.6.10 or later as soon as possible. The official downloads page marks 3.6.10 as the recommended stable build and includes the relevant SSH integration hardening note.

Until upgrades are complete, users should be careful with untrusted terminal output. Calif explicitly warns that malicious text can arrive through files, server responses, banners, or MOTDs, so the risk is not limited to downloading a suspicious document. Displaying hostile output in iTerm2 can be enough to start the bad protocol state.

Teams that rely heavily on SSH into unfamiliar systems should also review whether SSH integration is enabled where it is not strictly needed. Calif’s write-up shows the flaw lives in the conductor workflow itself, so reducing exposure to that feature can shrink risk until patching is complete. This last point is an inference from the published root cause and protocol path.

Recommended actions

• Upgrade iTerm2 to 3.6.10 or later.
• Avoid displaying untrusted text files or terminal output in vulnerable iTerm2 builds.
• Treat MOTDs, banners, and output from unfamiliar SSH servers as potentially hostile until patched.
• Review whether SSH integration is enabled by default in environments that do not need it. This recommendation follows from the documented attack path.
• Test developer fleets for iTerm2 3.6.9 and earlier, then prioritize upgrades on machines that frequently connect to external systems.

FAQ