**Short answer:** Vim is vulnerable to this kind of attack (while in Insert mode).

### Proof of concept ###

Using the linked article as a starting point, I was able to quickly create a web page with the following code, using HTML span elements and CSS to hide the middle part of the text so that only `ls -la` is visible to the casual viewer (not viewing the source). Note: the `^[` is the Escape character and the `^M` is the carriage return character. Stack Exchange sanitises user input and protects against hiding of content using CSS so I’ve uploaded the [proof of concept](http://ruant.info/html5/vim-copy-paste-proof-of-concept.html).

    ls ^[:echom "This could be a silent command."^Mi -la

If you were in Insert mode and pasted this text into terminal Vim (with some qualifiers, see below) you would see `ls -la` but if you run the `:messages` command, you can see the results of the hidden Vim command.

### Defence ###

To defend against this attack it’s best to stay in Normal mode and to paste using `"*p` or `"+p`. In Normal mode, when *p*utting text from a register, the full text (including the hidden part) is pasted. This same doesn’t happen in Insert mode (even if `:set paste`) has been set.

### Bracketed paste mode ###

Recent versions of Vim support *bracketed paste mode* that mitigate this type of copy-paste attack.  Sato Katsura has clarified that “Support for bracketed paste appeared in Vim 8.0.210, and was most recently fixed in version 8.0.303 (released on 2nd February 2017)”.

Note: As I understand it, versions of Vim with support for bracketed paste mode *should* protect you when pasting using <kbd>Ctrl</kbd>-<kbd>Shift</kbd>-<kbd>V</kbd> (most GNU/Linux desktop environments), <kbd>Ctrl</kbd>-<kbd>V</kbd> (MS Windows), <kbd>Command</kbd>-<kbd>V</kbd> (Mac OS X), <kbd>Shift</kbd>-<kbd>Insert</kbd> or a mouse middle-click.

### Testing ###

I did some testing from a Lubuntu 16.04 desktop machine later but my results were confusing and inconclusive. I’ve since realised that this is because I always use **GNU screen** but it turns out that *screen* filters the escape sequence used to enable/disable the bracketed paste mode (there is a [patch](https://lists.gnu.org/archive/html/screen-devel/2013-03/msg00000.html) but it looks like it was submitted at a time when the project was not being actively maintained). In my testing, the proof of concept always works when running Vim via GNU screen, regardless of whether Vim or the terminal emulator support bracketed paste mode.

Further testing would be useful but, so far, I found that support for bracketed paste mode by the terminal emulator block my Proof of Concept – as long as GNU screen isn’t blocking the relevant escape sequences. However, user *nneonneo* [reports](https://unix.stackexchange.com/questions/355610/is-vim-immune-to-copy-paste-attack/355620?noredirect=1#comment630223_355620) that careful crafting of escape sequences may be used to exit bracketed paste mode.

Note that even with an up-to-date version of Vim, the Proof of Concept always works if the user pastes from the `*` register while in Insert mode by typing (<kbd>Ctrl</kbd>-<kbd>R</kbd><kbd>\*</kbd>). This also applies to GVim which can differentiate between typed and pasted input. In this case, Vim leaves it to the user to trust the contents of their register contents. So don’t ever use this method when pasting from an untrusted source (it’s something I often do – but I’ve now started training myself not to).

### Related links ###

 * [What you see is not what you copy](http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinwyc/what_you_see_is_not_what_you_copy.txt) (from 2009, first mention of this kind of exploit that I found)
 * [Recent discussion on vim\_dev mailing list](https://groups.google.com/forum/#!topic/vim_dev/dYfZp7tMg5c) (Jan 2017)

### Conclusion ###

Use Normal mode when pasting text (from the `+` or `*` registers).

>! … or use Emacs. I hear it’s a decent operating system. :)