Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 17 Jun 2024 11:48:59 +1000
From: David Leadbeater <>
Cc: George Nachman <>, Vinci <>
Subject: Re: iTerm2 3.5.x title reporting bug


On Sat, 15 Jun 2024 at 11:37, David Leadbeater <> wrote:
> This is not trivially exploitable (at least in a way that works
> without user interaction), as it is not possible to echoback a newline
> or control characters. However as Zsh is the default shell on macOS it
> may be possible to use some of the vi techniques like I used in xterm
> CVE-2022-45063[1]. Some of the techniques in solid-snail's previous
> iTerm2 research[2] could apply too. So treat this as potential remote
> code execution.

I spoke too soon, this was independently discovered by Vin01 -- along
with a tmux integration issue. The additional finding by Vin01 allows
for remote code execution via the tmux escape sequence (as it allows a
newline to be inserted).

Their write up is available from

There are now two CVEs assigned:
- CVE-2024-38395 (title reporting, the original issue reported)
- CVE-2024-38396 (tmux integration, combined with title reporting)

The second commit (fc60236a) mentioned in the post is not yet part of
an iTerm2 release. Fixing the title reporting makes this harder to
exploit but fc60236a can be considered additional hardening for the
Tmux integration.


Copy of the above blog post for the archives, with minor reformatting,
all credit to Vin01:

# Abusing title reporting and tmux integration in iTerm2 for code execution
Jun 16, 2024

## Regression turned into RCE

I am skipping an introduction to escape sequences here as I recently
wrote more about them in my previous post[1]. From a security
perspective, they are to terminal emulators what XSS is to browsers.

This post is about a new bug which affects only iTerm2 3.5.0 and 3.5.1
(released on May 20 and June 11 respectively) because of a regression.

In versions prior to 3.5.0, window title reporting was disabled. So
you could not just use following to retrieve the title of terminal
window and put it in stdin.

$ echo -e "\e]21t"

Note: David Leadbeater also independently noticed this regression and
reported it here [this thread]

## What is wrong with window title reporting?

Ps 2[2] escape sequence allows setting the window title.

An example:

$ echo -e "\033]0;This is the window title\a"

CSI Ps 21 t can be used to retrieve that title and put it in stdin as
shown above. This makes exploitation very easy as at this point, all
that is required is for the user to hit Enter and arbitrary code
present in that title will happily execute itself.

Patch that disables title reporting by default: f1e89f78[4]

## Tmux integration made it worse

Native tmux integration (enabled by default) in iTerm2 had a weakness
which allowed sneaking in the reported title and also provided a way
to send newlines after the title was reported.

Patch: fc60236a[5]

## Can I haz that sweet PoC plz?

try this out yourself:

docker run --rm  vin01/escape-seq-test:cve-2024-38396


cat poc-iterm2-rce.txt

Download poc-iterm2-rce.txt[6]

The file contains this payload \033]2;s&open -aCalculator&\a\033[21t
\x1bP1000p%session-changed s which sets s&open -aCalculator& as window
title and then retrieves it back to execute and pop a calculator.

Source code:

## A fix released within 2 days of reporting

Upgrade to iTerm2 3.5.2:

Please think twice before you enable Terminal may report window title
setting in iTerm2. It might not be worth the security risk as it
allows arbitrary text to end up in stdin which is never a good idea.

[2]: [blog links to the pdf; is a newer
HTML version of the xterm control sequence documentation]

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.