Urxvt is one such terminal with that vulnerability, but it can be fixed with a small perl extension, like the one I provided here:
That answer also includes a table checking other terminals for that vulnerability.
The second example on the following page can be used to test a terminal for that variation of the attack:
I can paste newlines just fine in both alacritty and konsole, so I'm not sure what you mean. With support for Bracketed Paste Mode, all that needs to be stripped from the pasted content is the end-paste escape sequence.
Perhaps they stripped newlines before adding Bracketed Paste Mode. That must've been quite some time ago, though.
That's strange. I tried copy-pasting the text on https://thejh.net/misc/website-terminal-copy-paste to Alacritty, and the newlines were replaced with semicolons. However, pasting newlines worked within vim in insert mode. It happens with or without bracketed paste mode on (using the "enable-bracketed-paste" option in ~/.inputrc). Same thing with Konsole.
> > A few terminals, despite having Bracketed Paste Mode, are vulnerable to escape injection. That's when the end-paste escape sequence is included in the paste content, and the terminal lets it pass through, causing the shell to think the paste ended.
I'm glad you mentioned this!
> With support for Bracketed Paste Mode, all that needs to be stripped from the pasted content is the end-paste escape sequence.
Alacritty strips the control sequence that ends bracketed paste; https://github.com/alacritty/alacritty/issues/800.
~/.inputrc is the readline library's configuration file. The "enable-bracketed-paste" option in it doesn't affect vim nor the terminals. What it does is turn on the recognition of Bracketed Paste Mode escape sequences for programs that use readline, like bash.
> the newlines were replaced with semicolons
I can't reproduce. After setting that option in ~/.inputrc, bash puts multi-line pastes in a single prompt, but it keeps the newlines, not replace them. This is bash 5.0.18(1). Are you sure you're not confusing the semicolons that are really there and thinking they were newlines before?
In any case, a behavior like that would have to be done by the shell, not the terminal, since semicolons are not special to the terminal and it's not a simple matter of substituting one for the other in shell code. In order for the shell code to be equivalent, parsing would be required to identify if the newline terminates a command or if it's part of another syntax structure. For example
qux << EOF
EDIT: Maybe you have other bash configuration options playing into that substituting behavior. Bash shell options like cmdhist and lithist seem relevant. From the bash manpage:
> lithist If set, and the cmdhist option is enabled, multi-line commands are saved to the history with embedded newlines rather than using semicolon separators where possible.
So in this case, for instance, it's safer to first paste into a text editor, examine first, then paste.