CVE-2026-34982

What it actually does

This vulnerability is a Vim modeline sandbox bypass that can lead to arbitrary operating system command execution. Vim modelines allow files to embed editor settings that are applied when the file is opened. Before Vim 9.2.0276, the `complete`, `guitabtooltip`, and `printheader` options were missing the protection flag that prevents them from being set from modelines, and the `mapset()` function did not perform the required secure-context check. A crafted file can therefore cause Vim to evaluate attacker-controlled expressions from what should be a restricted modeline context and execute OS commands with the privileges of the user running Vim. The CVSS vector indicates local attack complexity is low, no prior privileges are required, user interaction is required, and successful exploitation can compromise confidentiality and integrity.

Why it matters to the business

An attacker who convinces a developer, administrator, or operator to open a malicious file in a vulnerable Vim version may be able to run commands as that user. In practical terms, this can expose source code, credentials, SSH keys, configuration files, deployment secrets, or allow tampering with files the user can modify. The risk is especially relevant in engineering, operations, and server administration workflows where Vim is commonly used to inspect untrusted files such as logs, patches, repository content, support bundles, or downloaded configuration snippets. Although this issue is not currently listed in CISA KEV, has low EPSS, no known exploit maturity in the provided data, and no ransomware association, the impact can still be high where privileged users open untrusted files.

How an attack unfolds

An attacker prepares a text file containing a malicious Vim modeline that abuses one of the affected options such as `complete`, `guitabtooltip`, or `printheader`, or uses the insecure `mapset()` behavior from a sandboxed expression. The attacker then delivers the file through a channel where a target is likely to inspect it with Vim, such as a source repository, patch, archive, log file, configuration file, support attachment, or downloaded text artifact. When the victim opens the file in a vulnerable Vim version with modeline processing enabled, Vim parses the modeline and applies the embedded settings. Because the affected options and function were not properly restricted, the modeline can escape the intended sandbox and trigger command execution. The command runs locally under the victim user's account, allowing the attacker to read accessible files, alter repository content, implant shell startup hooks, create persistence in user-writable locations, or stage additional payloads.

How to fix it

Upgrade Vim to version 9.2.0276 or later, or apply the upstream fix corresponding to commit 9.2.0276 from the vendor or distribution package maintainer. Because Vim is commonly distributed through operating system package repositories, verify the fixed package version with the relevant Linux, Unix, macOS, or Windows package provider rather than relying only on the upstream version string. If immediate upgrade is not possible, reduce exposure by disabling modelines for untrusted files using `set nomodeline`, `set modelines=0`, or equivalent global configuration, and avoid opening untrusted files with Vim on privileged accounts. Administrators should also consider enforcing safer editor defaults in system-wide Vim configuration files and encouraging users to inspect unknown files with tools that do not evaluate embedded editor directives.

How to confirm the fix worked

Confirm that installed Vim builds include the 9.2.0276 fix or a vendor backport. Run `vim --version` and compare the reported patch level or package changelog against the fixed release. On package-managed systems, query the installed package metadata and vendor advisory to confirm the fix is present. Validate configuration by checking user and system Vim configuration for `nomodeline` or `modelines=0` where modelines are intentionally disabled. For exposure testing in a controlled lab only, open a benign proof-of-concept file that exercises modeline handling and confirm that protected options cannot be set from a modeline and that sandboxed expressions cannot invoke unsafe behavior. Do not test with payloads that execute real commands on production systems.

Typical attack path

1. Identify users or workflows likely to open attacker-supplied or externally sourced files in Vim.
2. Craft a file containing a malicious Vim modeline using an affected option or sandbox bypass primitive.
3. Deliver the file through a repository, patch submission, attachment, shared archive, issue tracker, chat message, support bundle, or similar file exchange path.
4. Wait for the target to open the file with a vulnerable Vim version prior to 9.2.0276.
5. Vim processes the embedded modeline and evaluates attacker-controlled content outside the intended sandbox restrictions.
6. The attacker-controlled command executes with the privileges and environment of the user running Vim.
7. Use the resulting execution to access sensitive local files, modify files, exfiltrate credentials, or stage follow-on commands.

How to detect it

To determine whether exploitation already occurred, review endpoint telemetry, shell history, process creation logs, EDR events, and file access logs for suspicious commands spawned by Vim. Focus on cases where `vim`, `vi`, `view`, `gvim`, or related editor binaries launched child processes such as `sh`, `bash`, `zsh`, `cmd.exe`, `powershell.exe`, `python`, `perl`, `ruby`, `curl`, `wget`, `nc`, `ssh`, or archive/exfiltration tools. Search recently opened files, repositories, patches, support bundles, and downloaded text files for Vim modelines containing suspicious use of `complete`, `guitabtooltip`, `printheader`, `mapset(`, shell metacharacters, command substitutions, or calls to external interpreters. On Linux and Unix systems, review auditd, syslog, EDR, terminal logging, and user shell history for command execution near the time suspicious files were opened. On macOS, review unified logs and EDR process trees. On Windows, review Sysmon Event ID 1, Security 4688, PowerShell logs, and EDR process trees for editor-to-shell execution chains. Because payloads are attacker-controlled and may leave few durable artifacts, prioritize behavioral evidence: Vim spawning unexpected child processes, modification of shell startup files, newly created user-level persistence files, and network connections initiated shortly after a file was opened.

• vim: set complete=
• vim: set guitabtooltip=
• vim: set printheader=
• vi: set complete=
• vi: set guitabtooltip=
• vi: set printheader=
• ex: set complete=
• ex: set guitabtooltip=
• ex: set printheader=
• mapset(
• modeline
• vim -> sh
• vim -> bash
• vim -> zsh
• vim -> dash
• vim -> ksh
• vim -> cmd.exe
• vim -> powershell.exe
• vim -> python
• vim -> python3
• vim -> perl
• vim -> ruby
• vim -> curl
• vim -> wget
• vim -> nc
• gvim -> sh
• gvim -> bash
• gvim -> cmd.exe
• gvim -> powershell.exe

What your security team should do

• Inventory systems, developer workstations, build hosts, and administrative jump boxes where Vim is installed, prioritizing users who handle untrusted files or operate with elevated privileges.
• Upgrade Vim to 9.2.0276 or a vendor-backported fixed package as soon as practical.
• Until upgraded, disable Vim modelines globally or for users who regularly inspect untrusted files.
• Warn developers and administrators not to open unsolicited patches, logs, configuration files, or repository content in vulnerable Vim versions.
• Review repositories, issue attachments, and shared text artifacts for suspicious Vim modelines referencing `complete`, `guitabtooltip`, `printheader`, or `mapset()`.
• Hunt for unusual child processes spawned by Vim, especially shells, download utilities, scripting runtimes, or credential-access commands.
• Treat any confirmed exploitation under a privileged user account as a potential credential and source-code exposure event.
• Add secure editor configuration checks to workstation and server hardening baselines.