Hi,
The paste-buffer command writes paste content directly to the pane pty via bufferevent_write() (cmd-paste-buffer.c:97-103) with no filtering of escape sequences. When bracketed paste is active (the default ] binding uses paste-buffer -p), the content is wrapped in \033[200~ / \033[201~ markers, but the content itself is never inspected.
If paste buffer content contains the bracketed paste end marker \033[201~, it terminates bracketed paste mode early. Anything after that marker is interpreted by the shell as direct keyboard input rather than pasted text.
This is a well-known vulnerability class with CVEs in other terminals (PuTTY CVE-2019-17068, MinTTY CVE-2021-31701, Xshell CVE-2021-37326, among others). xterm, kitty, WezTerm, GNOME VTE, PuTTY, and MinTTY all sanitize paste content now. tmux does not.
The issue exists regardless of how the paste buffer is populated. tmux set-buffer with crafted content triggers it. When set-clipboard is "on" (non-default), OSC 52 escape sequences provide another path: the base64-decoded content is stored raw via paste_add() (input.c:3184) with no filtering.
Suggested fix:
strip or replace \033[200~ and \033[201~ sequences from paste buffer content before writing to the pty in cmd-paste-buffer.c. This matches the approach taken by WezTerm and others.
To reproduce:
tmux set-buffer "$(printf '\033[201~\rid\r#')"
# Press prefix+] in a shell
# "id" executes as a command
Note this repro uses set-buffer directly, so set-clipboard is irrelevant. The unsanitized output path is the fundamental issue.
Tested on current master (8356578a)
Cheers,
Mason
--
Mason Davis Staff Security Engineer
Praetorian
|