CVE-2026-73076 is a code injection flaw in the Vim vimball plugin. A crafted vimball can overwrite the record file that tracks installs, and the commands stored there run later with the privileges of the user running Vim. The record scores it 7.8, High. Upgrade to Vim 9.2.0847.
What's affected
The record and the advisory both say Vim before 9.2.0847 is affected and that 9.2.0847 is the fixed patch level. The flaw is in runtime/autoload/vimball.vim.
The advisory explains the mechanism. The plugin records the files it extracts in a plain text file called .VimballRecord so that they can be removed later. Each line holds the commands that undo one install, and Vim ran them without checking. The plugin refused to extract members whose names could inject into the record, but did not refuse a member that is the record file itself. A crafted vimball can write chosen commands into the record, and they run the next time a vimball operation reads it, such as vimball#RmVimball(). The record notes that operating system commands run through the bang command execute with the user's privileges.
The weakness classes are CWE-94 and CWE-829.
How to check if you're exposed
Check the patch level of every Vim you run, including copies on servers, jump hosts and developer machines.
vim --version | head -3
vim --version | grep 'Included patches'
The second line prints a range such as 1 to a four digit number. The version is safe for this issue if that number is at least the fixed patch level. Linux distributions often backport fixes without changing the upstream patch number, so also check your distribution's security notes for the package. Vim is often installed by default on servers, in container base images and in CI images, so scan image contents too. The free in-browser scan at gold.safeguard.sh/scan can check a manifest for known CVEs.
Then check whether the plugin is in use. Look for a .VimballRecord file in your Vim runtime directories, usually under your home Vim directory. If it exists, read it before you run any vimball removal, and compare its lines with the plugins you actually installed.
What to do now
- Upgrade Vim to patch level 9.2.0847 or later, or install your distribution's fixed package.
- Do not open or source vimball archives from untrusted sources.
- Inspect any existing .VimballRecord file for lines you do not recognise before running a removal.
- Prefer plugin managers that fetch from sources you control.
- Update container and CI images that include Vim.
- Record the patch level you now run.
Why it matters
A record file that is later executed is a classic trap. The program writes data that it will read as commands, and any path that lets an outside file write into that record changes what the program does later, perhaps long after the bad file was opened. The plugin guarded against names that could inject into the record, but missed the record itself.
The sources differ on severity. The record scores it 7.8 under CVSS 3.1 and rates it High. The Vim GitHub advisory labels it Moderate and its text says Medium. Local attack vectors and a need for user action are the reason the project rates it lower. Plan around your own use. A shared jump host where many people open files from others is a bigger risk than a single user laptop. No source reports exploitation in the wild, and the CVE is not in the CISA KEV catalog. Because the commands may run later, the person who runs them may not connect the event to the vimball they opened.
Quick check
When do the injected commands run?
The next time a vimball operation reads the record, such as removing an installed vimball.
What is the fixed patch level?
Vim 9.2.0847.
Sources
Last reviewed: 18 October 2026.
