CVE-2026-47162: Vim netrw Code Injection Vulnerability – Arbitrary Code Execution

Technical summary

The vulnerability exists in the s:NetrwBookHistSave() function within the netrw plugin's autoload module (runtime/pack/dist/opt/netrw/autoload/netrw.vim). The function serializes directory paths visited during file browsing into Vimscript code that is written to ~/.vim/.netrwhist. Directory names sourced from the filesystem are directly interpolated into single-quoted Vimscript string literals without escaping single quotes. An attacker-controlled directory name containing unescaped single quotes can break the string context, allowing injection of arbitrary Vimscript statements. When the history file is sourced on subsequent Vim invocations, the injected code executes with the privileges of the user running Vim, including access to shell execution functions like system() and the :! command. This represents a classic code injection flaw (CWE-94) compounded by unsafe string serialization (CWE-140) and expression language injection (CWE-74).

Business impact

For organizations where developers, sysadmins, or security teams regularly use Vim across shared or untrusted environments, this vulnerability poses a privilege escalation and code execution risk. An attacker who can create directories with malicious names on a shared filesystem or compromised system could silently inject code that executes when a victim user opens Vim. This could lead to credential theft, lateral movement, or persistent backdoors within developer toolchains or CI/CD environments. The requirement for user interaction (opening Vim to trigger history loading) slightly limits the attack surface, but the risk is elevated in environments where directory traversal or file creation by untrusted parties is possible.

Affected systems

Vim versions prior to 9.2.0495 are affected. All users of Vim who have the netrw plugin active (which is the default for many Vim installations) are potentially vulnerable. The vulnerability is platform-agnostic and affects Linux, macOS, Windows, and other Unix-like systems where Vim is deployed. Both interactive users and automated systems that invoke Vim to browse or interact with the filesystem are in scope.

Exploitability

The attack requires that an attacker can create or control a directory name on a filesystem that a Vim user will browse using netrw. In local or network-accessible scenarios (NFS mounts, shared drives, cloned repositories with malicious directory names), the bar for exploitation is relatively low. The attack is not remotely exploitable without some means of placing a crafted directory on the target system first. User interaction is required—Vim must be opened and the netrw history must be sourced. No special Vim configuration is needed; default installations are vulnerable. The CVSS score of 8.8 (HIGH) reflects high impact (code execution as the user) combined with low attack complexity and no privilege requirements, moderated only by the user interaction requirement.

Remediation

Upgrade Vim to version 9.2.0495 or later. Verify your installed version by running `:version` within Vim or `vim --version` from the command line. Package managers (apt, brew, yum, etc.) should provide updated versions; check your distribution's Vim package. If you cannot upgrade immediately, avoid browsing untrusted or attacker-controlled directories using netrw, and consider disabling the netrw plugin if not essential for your workflow.

Patch guidance

Update Vim through your package manager or build from source. On Linux systems using apt: `sudo apt update && sudo apt upgrade vim`. On macOS with Homebrew: `brew upgrade vim`. For binary distributions and Windows, visit vim.org and download the latest release. After installation, verify the version with `vim --version` and confirm it shows 9.2.0495 or later. If you maintain Vim across a fleet of systems, prioritize updates in environments where users interact with diverse or untrusted filesystems.

Detection guidance

Monitor for Vim processes that load or source the ~/.vim/.netrwhist file, particularly in conjunction with unexpected Vimscript execution or shell command invocation. Look for netrwhist files containing suspicious Vimscript syntax (unbalanced quotes, function calls, system() invocations) that don't match typical directory path entries. In endpoint detection and response (EDR) systems, flag Vim spawning shells or subprocesses without explicit user command. On shared filesystems, scan for directory names containing Vimscript metacharacters (single quotes, pipes, semicolons) that could be injection payloads. Review .viminfo and shell history logs for anomalous Vim invocations or unexpected command execution.

Why prioritize this

This vulnerability should be prioritized for patching because it enables arbitrary code execution with user-level privileges, affecting a widely-used development tool. While exploitation requires directory-level control by an attacker, the risk is substantial in development environments, CI/CD pipelines, and shared filesystem scenarios. The default inclusion of netrw in most Vim installations and the silent nature of the attack (code execution occurs on history load, not during obvious user actions) make this a moderate-to-high priority for security teams. Organizations with strict filesystem access controls can lower prioritization slightly, but development teams and sysadmins should patch promptly.

Risk score, explained

The CVSS 3.1 score of 8.8 reflects: high impact (C:H, I:H, A:H—confidentiality, integrity, and availability all compromised through arbitrary code execution), low attack complexity (AC:L—no special conditions needed), network adjacency not required (AV:N accounts for mounting or accessibility via network protocols like NFS or SMB), no privilege escalation (PR:N), and user interaction required (UI:R—user must open Vim to trigger the vulnerability). The score does not include environmental factors; organizations with strict filesystem controls and isolated development environments may apply severity adjustments downward, while those with shared filesystems or CI/CD automation should view this as a critical issue.

Frequently asked questions