CVE-2026-55895

What it actually does

CVE-2026-55895 is a local, user-assisted Vimscript command injection flaw in Vim’s bundled netrw plugin before version 9.2.0663. When a user browses a local directory with netrw and deletes a file from the browser, netrw’s s:NetrwLocalRmFile() function builds an Ex command using a filename taken from the directory listing. Because only backslashes are escaped, a specially crafted filename containing command separators such as the vertical bar character can break out of the intended delete command and execute arbitrary Vimscript. That Vimscript can invoke shell commands through mechanisms such as :call system() or :!, resulting in code execution with the privileges of the user running Vim.

Why it matters to the business

Successful exploitation can turn a routine file-browsing or file-deletion action in Vim into arbitrary command execution on a developer workstation, administrator shell, build host, or server where Vim is used interactively. The most likely consequences are compromise of the current user account, theft or modification of source code and credentials accessible to that user, malware staging, and lateral movement from privileged operator systems. The vulnerability requires user interaction and has low observed exploitation probability based on current EPSS, is not known to be exploited by CISA KEV, and has no public exploit maturity indicated, but the affected component is widely present wherever Vim is installed, so patching remains important for developer and administrative environments.

How an attack unfolds

An attacker first needs to place or convince a user to access a directory containing a maliciously named file. This could occur through a downloaded archive, a shared repository, a removable drive, a network share, or any workflow where a user opens an untrusted directory in Vim’s netrw file browser. The attacker creates a filename that includes Ex command syntax, especially a bar character used to terminate the intended command and append attacker-controlled Vimscript. When the victim opens the directory using netrw and triggers local file deletion from the browser for that crafted entry, netrw interpolates the filename into an :execute command without sufficient escaping. Vim interprets the injected command sequence and runs the attacker’s Vimscript. If the payload uses :call system(), :!, or similar functionality, it can execute operating-system commands as the user running Vim. From there, the attacker may drop files, read secrets, alter source code, modify shell profiles, or establish persistence within the limits of the user’s privileges.

How to fix it

Upgrade Vim to version 9.2.0663 or later, which contains the netrw fix. Where operating-system packages are used, apply the vendor-provided Vim update that backports this fix, even if the displayed upstream version differs. Prioritize developer workstations, administrator jump hosts, build systems, and servers where users open untrusted directories or repositories in Vim. If immediate patching is not possible, mitigate by avoiding Vim netrw for untrusted directories, disabling or removing the netrw plugin where operationally acceptable, and treating archives or repositories containing unusual filenames as untrusted until inspected outside Vim. Users should avoid deleting files from netrw in directories received from untrusted sources until patched.

How to confirm the fix worked

Confirm that Vim reports version 9.2.0663 or later, or that the installed vendor package changelog explicitly includes the CVE-2026-55895/netrw command-injection fix. Validate package deployment through endpoint inventory, software management, or configuration management tooling across systems where Vim is installed. For functional validation in a controlled test environment only, create a harmless filename containing an Ex command separator and verify that deleting it through netrw does not execute unintended Vimscript or shell commands. Confirm that mitigations, if used, prevent netrw from loading or prevent users from browsing and deleting files from untrusted directories via netrw.

Typical attack path

1. Attacker creates a file with a malicious name containing Vim Ex command separators or payload syntax.
2. Attacker gets the crafted file into a location the target may browse with Vim netrw, such as a repository, archive, shared folder, or mounted directory.
3. Victim opens the directory in Vim’s netrw browser using a vulnerable Vim version before 9.2.0663.
4. Victim initiates deletion of the malicious local file from the netrw browser.
5. netrw passes an insufficiently escaped filename into an :execute command.
6. Injected Vimscript is interpreted by Vim and can launch shell commands.
7. Attacker-controlled commands run with the privileges and environment of the Vim user.

How to detect it

Look for evidence that Vim unexpectedly launched child processes or shell commands around the time a user was browsing or deleting files in a directory. Useful telemetry includes EDR process creation events, Sysmon or Linux auditd execve logs, shell history, terminal session recording, command-line logging, file creation events, and package or repository access logs. Focus on process trees where vim or gvim is the parent of sh, bash, zsh, dash, cmd, powershell, python, perl, curl, wget, nc, ncat, ssh, chmod, or other utilities not normally launched by an editor. Search file systems and recent archives/repositories for filenames containing Vim Ex command separators or command-like substrings, especially vertical bars, :call system, :!, curl, wget, or shell redirection characters. Investigate any suspicious files created or modified immediately after such Vim activity, including shell startup files, SSH authorized_keys, cron entries, systemd user units, temporary payloads, or scripts in writable directories. Because exploitation is user-assisted and filename-dependent, there may be no reliable network IOC; endpoint process lineage and anomalous filenames are the highest-value evidence sources.

• vim -> sh
• vim -> bash
• vim -> zsh
• vim -> dash
• vim -> cmd.exe
• vim -> powershell.exe
• gvim -> sh
• gvim -> bash
• gvim -> zsh
• gvim -> powershell.exe
• parent_process_name=vim process_name=sh
• parent_process_name=vim process_name=bash
• parent_process_name=vim process_name=zsh
• parent_process_name=gvim process_name=sh
• parent_process_name=gvim process_name=bash
• :call system(
• |call system(
• |!
• runtime/pack/dist/opt/netrw/autoload/netrw.vim
• s:NetrwLocalRmFile

What your security team should do

• Inventory Vim installations across developer, administrator, build, and Linux/Unix server endpoints, including container images and golden images.
• Patch or upgrade Vim to 9.2.0663 or the relevant vendor-fixed build, prioritizing systems used with untrusted repositories, archives, or shared directories.
• Notify developers and administrators not to use vulnerable Vim netrw to browse or delete files in untrusted directories until patched.
• Review recent endpoint telemetry for Vim spawning shells or script interpreters unexpectedly, especially after browsing downloaded repositories, archives, or shared folders.
• Add detections for Vim process trees that launch shell commands, network tools, credential-access commands, or file-download utilities.
• Where patching is delayed, consider disabling the netrw plugin or enforcing safer file-browsing workflows for untrusted content.
• Include Vim and bundled plugin versions in workstation and build-image vulnerability management baselines.