Ghostty's tmux control mode viewer creates a terminal for each pane using the width and height from the tmux layout, without validating them. A malicious byte stream written to the terminal can enter tmux control mode and send a layout containing a pane that is zero cells wide or tall. Creating that pane's terminal results in an assertion failure in safe builds and undefined behavior in release builds, including out-of-bounds memory access, which in practice causes Ghostty to crash. A pane width larger than 65535 has the same effect, because the value wraps when it is converted to a column count.
The checksum on tmux layouts does not prevent this. It only detects accidental corruption and can be computed by anyone.
This can be triggered by any program that can write to the terminal, such as a remote server over SSH or viewing a malicious file with cat . It does not require tmux to be installed. A crash terminates the entire Ghostty process, including all windows, tabs, and splits.
No confidentiality or integrity impact has been demonstrated.
libghostty-vt is not affected because tmux control mode is not enabled in libghostty-vt builds.
Fixed in Ghostty v1.4.0.
tmux layouts that contain a pane with a zero width or height are now rejected, and pane sizes that don't fit in a terminal are rejected before the pane is created. When this happens, Ghostty stops handling tmux control mode for that session instead of crashing. Terminals also now refuse to be created with zero rows or columns, no matter where the size comes from.
There are no workarounds.
tmux control mode cannot be disabled at runtime in affected versions.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
