CVE-2026-47167

What it actually does

This vulnerability affects Vim versions prior to 9.2.0496 when built with Ruby support (+ruby). The vulnerable cucumber filetype plugin reads step-definition patterns from Ruby files under repository paths such as features/*/ or stories/*/ and embeds those patterns into a Ruby Kernel.eval call without sufficient escaping. If a user opens an attacker-controlled repository and invokes the cucumber step-jump mappings, such as [d or ]d, a malicious step pattern can cause arbitrary Ruby code execution. Because Ruby can invoke operating-system commands, this can lead to arbitrary command execution in the context of the user running Vim.

Why it matters to the business

An attacker can weaponize a source-code repository so that a developer, tester, or engineer who opens it in a vulnerable Vim build and uses cucumber step navigation unknowingly runs attacker-supplied commands. Practical consequences include theft of source code, credentials, SSH keys, API tokens, local development secrets, and modification of project files. The CVSS score and EPSS are currently low, it is not known to be in CISA KEV, and no public exploit maturity is reported, but the risk is meaningful for organizations where developers frequently inspect untrusted repositories or external contributions.

How an attack unfolds

An attacker prepares a repository containing crafted Cucumber Ruby step-definition files under paths processed by Vim's cucumber filetype plugin, such as features/*/ or stories/*/. The malicious step pattern is designed so that when the plugin builds a Ruby expression for step matching, the pattern breaks out of the intended string or expression context and injects attacker-controlled Ruby code. The attacker then convinces a victim to clone, open, review, or otherwise work in the repository using a vulnerable Vim build compiled with +ruby. Exploitation requires user interaction: the victim must invoke the vulnerable step-jump functionality, commonly through the [d or ]d mappings. Once triggered, Vim evaluates the constructed Ruby expression through Kernel.eval, executing the injected Ruby code with the victim user's privileges. The Ruby payload may directly alter files, read local secrets, or launch shell commands such as curl, wget, bash, sh, python, or other tooling to stage additional malware or exfiltrate data.

How to fix it

Upgrade Vim to version 9.2.0496 or later, which contains the patch for the vulnerable cucumber filetype plugin behavior. Where immediate upgrade is not possible, reduce exposure by disabling Ruby support in Vim builds, avoiding use of the cucumber filetype plugin for untrusted repositories, disabling filetype plugins globally or selectively for cucumber files, and avoiding the [d and ]d cucumber step-jump mappings when working with untrusted code. Treat repositories from external contributors, public forks, challenge projects, and unsolicited archives as untrusted until reviewed. Developer workstations and CI/devcontainer images that include Vim should be updated, especially where Vim is used to inspect third-party code.

How to confirm the fix worked

Confirm the installed Vim version is 9.2.0496 or later by running vim --version and checking the patch level. Also check whether the build includes +ruby; systems without Ruby support are not exposed to this specific execution path. Validate that runtime/ftplugin/cucumber.vim comes from a patched Vim distribution. On managed fleets, inventory Vim packages from OS package managers, language/devcontainer images, and manually installed binaries. For mitigation validation, verify that filetype plugins are disabled where intended, that cucumber.vim is not loaded for untrusted repositories, or that Ruby support is absent. If testing in a lab, use a non-production sandbox and confirm that crafted cucumber step definitions no longer result in Ruby evaluation or command execution when [d or ]d is invoked.

Typical attack path

1. Attacker creates or modifies a repository containing malicious Cucumber step-definition Ruby files under features/*/ or stories/*/.
2. Attacker embeds a crafted step-definition pattern that injects Ruby code into the expression evaluated by Vim's cucumber plugin.
3. Victim clones, opens, or reviews the repository using Vim prior to 9.2.0496 built with +ruby support.
4. Victim invokes the cucumber step-jump mapping, such as [d or ]d, while editing or navigating Cucumber-related files.
5. The vulnerable plugin passes attacker-controlled content into Ruby Kernel.eval without sufficient escaping.
6. Injected Ruby executes in the Vim process with the victim user's permissions.
7. Payload performs local actions such as reading files, stealing credentials, modifying source code, or launching shell commands for persistence, download, or exfiltration.

How to detect it

To determine whether this was already exploited, review endpoint process telemetry, shell history, EDR events, and file modification activity for cases where vim, gvim, or a terminal-hosted Vim process spawned unexpected child processes. Focus on child processes such as /bin/sh, bash, zsh, ruby, python, perl, curl, wget, nc, ssh, scp, or cloud/package-manager CLIs. Correlate suspicious Vim child processes with recent git clone, archive extraction, or opening of repositories containing Cucumber files and Ruby step definitions under features/ or stories/ directories. Review repository contents for unusual Ruby step-definition patterns that include command execution, backticks, %x{}, system, exec, spawn, IO.popen, Open3, File.read of sensitive paths, network calls, or obfuscated Ruby. Examine shell histories, EDR command-line capture, DNS/proxy logs, and outbound firewall logs around the time of Vim activity for downloads or exfiltration. On macOS and Linux, inspect auditd, osquery, EDR, terminal logs, and process accounting where available. On Windows environments using Vim/gVim, inspect Sysmon, PowerShell logs, Windows Security logs, and EDR process trees for gvim.exe or vim.exe spawning cmd.exe, powershell.exe, wscript.exe, curl.exe, certutil.exe, or other unusual utilities. Because exploitation depends on user interaction and arbitrary attacker payloads, there may be no universal network or file IOC; process lineage from Vim to unexpected commands is the most reliable detection pattern.

• runtime/ftplugin/cucumber.vim
• features/*/*.rb
• stories/*/*.rb
• Kernel.eval
• ParentImage=vim ChildImage=/bin/sh
• ParentImage=vim ChildImage=/bin/bash
• ParentImage=vim ChildImage=/bin/zsh
• ParentImage=vim ChildImage=curl
• ParentImage=vim ChildImage=wget
• ParentImage=vim ChildImage=python
• ParentImage=vim ChildImage=ruby
• ParentImage=gvim.exe ChildImage=cmd.exe
• ParentImage=gvim.exe ChildImage=powershell.exe
• ParentImage=gvim.exe ChildImage=curl.exe
• ParentImage=gvim.exe ChildImage=certutil.exe
• system(
• exec(
• spawn(
• IO.popen
• Open3.popen
• %x{
• `curl
• `wget

What your security team should do

• Prioritize upgrading Vim to 9.2.0496 or later on developer workstations, build images, bastion hosts, and engineering environments where source repositories are reviewed.
• Inventory Vim builds for +ruby support using vim --version; prioritize remediation for builds showing +ruby.
• Warn developers not to open or navigate untrusted Cucumber repositories with vulnerable Vim versions, especially repositories from public forks, unsolicited archives, or unknown contributors.
• If patching is delayed, disable Vim filetype plugins or specifically prevent loading of the cucumber filetype plugin for untrusted code review workflows.
• Hunt endpoint telemetry for Vim spawning shells, interpreters, download tools, or network utilities, particularly shortly after opening newly cloned repositories.
• Review recent suspicious repository checkouts containing Cucumber Ruby step definitions under features/ or stories/ paths if followed by unusual child processes from Vim.
• Add EDR/SIEM detections for vim or gvim launching sh, bash, zsh, curl, wget, python, ruby, perl, nc, or similar tools.
• Treat any confirmed exploitation as potential developer credential compromise and rotate exposed SSH keys, access tokens, package registry credentials, and cloud credentials.