Vim Cucumber Plugin Code Injection Lets Malicious Repos Execute Ruby
Vim disclosed a medium-severity code injection flaw in its Cucumber filetype plugin that affects versions earlier than 9.2.0496 when compiled with +ruby support. The bug is in s:stepmatch() in runtime/ftplugin/cucumber.vim, where attacker-controlled step-definition regex patterns from repository .rb files were inserted into Ruby Kernel.eval() without sufficient escaping, allowing arbitrary Ruby execution and potentially shell command execution. The issue is tracked in GitHub Security Advisory GHSA-4473-94jm-w5x9 and mapped to CWE-94 and CWE-95.
Exploitation requires a user to open a malicious cucumber-style repository and trigger the step-jump mappings [d] or ]d on a matching feature line; the vulnerability does not fire through omni-completion alone because CucumberComplete() does not call the vulnerable path. Vim fixed the bug in patch 9.2.0496 by replacing Kernel.eval() with Regexp.new(), keeping the regex as untrusted data rather than executable code, and added a regression test using a proof-of-concept payload that attempted to invoke system("touch ..."). The project credited Aisle Research for reporting and analyzing the flaw.
Get ahead of threats like this
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
How this story unfolded
4 events from the most recent confirmed update back to the earliest known activity.
oss-sec notice publishes details of the Vim code injection issue
An oss-sec mailing list post announced the Vimscript code injection vulnerability in the cucumber filetype plugin, including affected versions, exploitation requirements, and the availability of patch 9.2.0496. The notice also credited Aisle Research for reporting and analysis.
GitHub advisory GHSA-4473-94jm-w5x9 discloses the Vim flaw
A GitHub Security Advisory publicly disclosed the medium-severity vulnerability affecting Vim versions earlier than 9.2.0496 and described the exploitation conditions, affected component, and impact. The advisory noted that a CVE had been requested but was not yet assigned.
Vim releases patch 9.2.0496 to fix the vulnerability
Vim fixed the cucumber plugin vulnerability in patch v9.2.0496 by replacing the unsafe Kernel.eval() usage with Regexp.new(), preventing untrusted regex data from being executed as code. The patch also added a regression test with a proof-of-concept payload to verify the exploit no longer works.
Aisle Research reports Vim cucumber plugin code injection flaw
Aisle Research identified and reported a code injection vulnerability in Vim's cucumber filetype plugin, where attacker-controlled step-definition regex patterns could reach Ruby's Kernel.eval() in s:stepmatch(). The issue affected Vim builds with +ruby support and could lead to arbitrary Ruby and shell command execution when users invoked step-jump mappings in a malicious repository.
Related entities
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Sources
3 references tracked. Mallory keeps watching after this page renders.
Vimscript Code Injection in cucumber filetype plugin via crafted step-definition regex affects Vim < 9.2.0496 · Advisory · vim/vim · GitHub
github.com
Open sourcepatch 9.2.0496: [security]: Code Injection in cucumber filetype plugin · vim/vim@a65a52d · GitHub
github.com
Open sourceoss-sec: [vim-security] Vimscript Code Injection in cucumber filetype plugin via crafted step-definition regex affects Vim < 9.2.0496
seclists.org
Open sourceSee the full picture, correlated to your attack surface.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Related stories
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Vim modeline flaw enables arbitrary command execution via crafted files
A high-severity flaw in **Vim** allows arbitrary OS command execution when a user opens a specially crafted file in affected versions earlier than **9.2.0272**. The bug chain abuses the `tabpanel` option, which was missing the `P_MLE` flag and therefore let modelines inject `%{expr}` expressions even when `modelineexpr` was not enabled; the injected code was then able to escape the sandbox because `autocmd_add()` lacked a `check_secure()` call. The issue affects builds compiled with `+tabpanel`, including common `FEAT_HUGE` builds, and executes with the privileges of the user running Vim. Vim fixed the issue in patch **v9.2.0272** via commit `664701eb7576edb7c7c7d9f2d600815ec1f43459`, and the vulnerability is tracked as **CVE-2026-34714** and **GHSA-2gmj-rpqf-pxvh**. Follow-on discussion on `oss-sec` focused on both CVE coordination and safer defaults for modelines. Maintainers said GitHub Support declined to assign a CVE because one had already been issued, while participants identified the record as **CVE-2026-34714**, reportedly assigned by MITRE. Security researchers and community members also argued that Vim's `modeline` feature remains risky for untrusted files because it is enabled by default in many environments, recommending mitigations such as setting `nomodeline` and moving toward a whitelist-based modeline design or disabling the feature by default; commenters noted that Debian, and likely Ubuntu, have already shipped with modelines disabled by default for years.
Jun 8, 2026
Vim Python Omni-Completion Flaws Enable Local Code Execution
Vim disclosed two medium-severity local code execution flaws in its Python omni-completion feature that can run attacker-controlled code when a user opens a malicious Python file and manually triggers completion, such as with `CTRL-X CTRL-O`. The first issue affects versions before `9.2.0561` and stems from the completer re-executing harvested `import` statements, which can load attacker-controlled sibling modules from the working directory in builds compiled with `+python3` or legacy `+python` and with filetype plugins enabled. Vim fixed that behavior in patch `9.2.0561` by disabling execution of harvested imports by default and allowing trusted users to re-enable it with `g:pythoncomplete_allow_import = 1`. A second flaw, later assigned **CVE-2026-52860**, affects versions before `9.2.0597` and bypasses that earlier mitigation because Vim reconstructs Python function and class definitions from the current buffer and executes them with `exec()`. That allows attacker-controlled default values, annotations, and class base expressions to run inside the user's Vim process when omni-completion is invoked, including by plugins that call the completion function. Vim said the issue does not affect builds without Python support and released patch `9.2.0597`; the disclosures credit **tonghuaroot** for the earlier bug and **DavidCarliez** for reporting and analyzing the later `exec()`-based issue.
Jun 11, 2026
Vim Modeline Bypass Enables Arbitrary Command Execution
Vim disclosed a high-severity vulnerability that lets attackers achieve arbitrary OS command execution when a user opens a crafted file in affected versions earlier than **9.2.0276**. The flaw is a modeline sandbox bypass caused by missing security-related `P_MLE` flags on the `complete`, `guitabtooltip`, and `printheader` options, allowing unsafe behavior from modelines that should have been restricted. The bug also involves a missing `check_secure()` call in `mapset()`, which creates additional exploitation paths through key mappings and option handling. Researchers showed that the `complete` option could abuse `F{func}` callback syntax without the protections applied to `completefunc`, while `guitabtooltip` and `printheader` could be leveraged through `mapset()`. Vim fixed the issue in patch **v9.2.0276**, and the advisory was later assigned **CVE-2026-34982**; the project credited **dfwjj x** and **Avishay Matayev** for the discovery and analysis.
Apr 2, 2026