This was reported by gentoo to vendor-sec Ciaran McCreesh, our Gentoo vim maintainer, found and reported upstream several modeline-related vulnerabilities in vim : ------------------------------------------------------------ It's possible to do some pretty nasty stuff via vim modelines despite the existing security code. For example, by passing evil values for a fileformat setting in a modeline, it's possible to make vim source arbitrary scripts upon startup. This would hurt on a multiuser system. Here's one way: User 'fred' creates a file in /home/fred/evil.vim containing lots of nastiness (for example, "system('echo alias vim=emacs >> ~/.bashrc') | quit"). He then creates a file in some shared location with a modeline which does something like"set ft=../../../*fred/evil". User 'joe', who has ftplugins and modelines enabled, edits this file. This results in a call of ":runtime!../../../*fred/evil" , which (assuming ~/.vim is in runtimepath) expands to ~/.vim/../../../*fred/evil which matches /home/fred/evil.vim. ------------------------------------------------------------ Bram Moolenaar provided the following vim patch, that fixes the reported vulnerabilities and adds more conservative modeline rights : ------------------------------------------------------------ Patch 6.3.045 Problem: Unusual characters in an option value may cause unexpected behavior, especially for a modeline. (Ciaran McCreesh) Solution: Don't allow setting termcap options or 'printdevice' or 'titleold' in a modeline. Don't list options for "termcap" and "all" in a modeline. Don't allow unusual characters in 'filetype', 'syntax', 'backupext', 'keymap', 'patchmode' and 'langmenu'. Files: src/option.c, runtime/doc/options.txt
Treat this issue as embargoed for now. While it is technically public, it's not well known.
Lifting embargo
FC3 packages with a fix pushed and announced