Description of problem:

Jan Minar has reported the following problem present in Vim shellescape() function implementation and demonstrated by testcases in tar.vim plugin:

The implementation of the shellescape() function does not properly escape all special items, in particular the '!' character). This can result in untrusted data being insufficiently sanitized and possibly lead to arbitrary code execution.

To show this vulnerability can be exploited, the tar.vim plugin test cases has been updated (tarplugin, tarplugin.v2 and tarplugin.updated test cases).

CVE-2008-3074 has been pre-assigned and used in rPath advisory:

http://www.openwall.com/lists/oss-security/2008/07/10/7

References:

http://www.rdancer.org/vulnerablevim-shellescape.html http://www.openwall.com/lists/oss-security/2008/07/15/2 http://www.openwall.com/lists/oss-security/2008/07/10/7 http://www.rdancer.org/vulnerablevim.html http://www.openwall.com/lists/oss-security/2008/07/13/1 http://www.openwall.com/lists/oss-security/2008/08/01/1

Last updated 13 July 2026

An issue in Vim Project v9.2.0389 and earlier allows a local attacker to execute arbitrary code via the vmsfixfilename() function within file vim/src/osvms.c

Last updated 2 July 2026

autoload/netrw.vim (aka the Netrw Plugin) 109, 131, and other versions before 133k for Vim 7.1.266, other 7.1 versions, and 7.2 stores credentials for an FTP session, and sends those credentials when attempting to establish subsequent FTP sessions to servers on different hosts, which allows remote FTP servers to obtain sensitive information in opportunistic circumstances by logging usernames and passwords. NOTE: the upstream vendor disputes a vector involving different ports on the same host, stating "I'm assuming that they're using the same id and password on that unchanged hostname, deliberately."

Vim is an open source, command line text editor. Prior to 9.2.0736, the PHP omni-completion script in runtime/autoload/phpcomplete.vim interpolates a class or trait name, taken from the contents of the edited buffer, into a search() pattern that is run via winexecute() without escaping. A name containing a single quote can terminate the search() string argument early, and because the bar is honored as an Ex command separator, the remainder of the name is run as Ex commands; via the :! command this allows arbitrary operating-system command execution when a victim opens a crafted PHP file and invokes omni-completion. This issue is fixed in version 9.2.0736.

Heap-based Buffer Underflow in Emacs tags parsing affects Vim < 9.2.0075 ======================================================================== Date: 27.02.2026 Severity: Medium CVE: CVE-2026-28419 CWE: Heap-based Buffer Underflow (CWE-124) / Out-of-bounds Read (CWE-125)

Summary A heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer.

Description The vulnerability is located in the emacstagsparseline() function in src/tag.c. When parsing Emacs-style tags that use the "second format" (where the tag name is not explicitly provided), the code attempts to isolate the tag name by scanning backward from the 0x7f delimiter.

If the 0x7f delimiter is located at the very beginning of the line (p7f == lbuf), the pointer arithmetic p = p7f - 1 results in a pointer that precedes the start of the heap-allocated buffer. The code then dereferences this pointer in the vimiswordc() check before verifying the buffer bounds, leading to an out-of-bounds read.

Impact An attacker who induces a user to perform a tag lookup using a crafted Emacs tags file can trigger a 1-byte out-of-bounds read. This can lead to a crash (Denial of Service).

The severity is rated medium because it is a 1-byte read-only underflow and requires user interaction with a malicious file.

Acknowledgements The Vim project would like to thank GitHub users ehdgks0627 and un3xploitable for identifying the vulnerability and providing a proof-of-concept.

References The issue has been fixed as of Vim patch v9.2.0075.

Commit Github Advisory

Thanks, Christian -- Ein edler Mensch zieht edle Menschen an und weiß sie festzuhalten. -- Johann Wolfgang von Goethe (Torquato Tasso)

Heap-based Buffer Overflow in Emacs tags parsing affects Vim < 9.2.0074 ====================================================================== Date: 27.02.2026 Severity: Low CVE: CVE-2026-28418 CWE: Heap-based Buffer Overflow (CWE-122) / Out-of-bounds Read (CWE-125)

Summary A heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary.

Description The vulnerability is located in the emacstagsnewfilename() function. When Vim encounters a section header in an Emacs-style tags file, it reads the following line into a fixed 512-byte heap buffer.

The code then searches for a comma delimiter to separate the filename from the section metadata. If a crafted tags file provides a line exceeding the buffer capacity without a comma, the search loop reaches the end of the allocation.

Because the code assumes a comma was found, it proceeds to check for an "include" directive by accessing memory immediately following the buffer boundary. This results in an out-of-bounds read of up to 7 bytes.

Impact The vulnerability allows for an out-of-bounds heap read. An attacker who induces a user to perform a tag lookup using a crafted Emacs tags file (e.g., in a malicious repository) can crash Vim.

The severity is rated low because it is a read-only overflow and requires the user to load and interact with a malicious emacs tags file.

Acknowledgements The Vim project would like to thank the reporter Github users ehdgks0627 and un3xploitable for identifying the vulnerability and providing a proof-of-concept.

References The issue has been fixed as of Vim patch v9.2.0074.

Commit Github Advisory

Thanks Christian -- Ein einziger Aufwiegler taugt manchmal mehr als alle Abwiegler zusammen. -- Georg Büchner