CVE-2026-33412

What it actually does

Vim before 9.2.0202 on Unix-like systems can pass attacker-controlled input from the glob() function into shell command processing when the glob pattern contains a newline character. If a user opens or sources malicious Vim script, filetype/plugin content, modeline-adjacent workflow content, or another input path that causes Vim to evaluate a crafted glob() call, the newline can break the intended pattern context and allow arbitrary shell commands to run with the privileges of the Vim user. Impact depends on the user's configured 'shell' option and execution context. The flaw is local and requires user interaction, but successful exploitation can modify files, steal user-accessible data, or establish persistence under that user's account.

Why it matters to the business

This vulnerability can turn routine use of a common command-line editor into unintended command execution on developer workstations, build hosts, administration jump boxes, or Unix servers where users edit untrusted files or use third-party Vim plugins. Although the EPSS score is low, there is no known KEV listing, no known ransomware use, and no public exploit maturity reported, Vim is widely deployed across Unix-like environments, so exposure may be broad and difficult to inventory. The most likely business consequences are compromise of user accounts, tampering with source code or configuration files, theft of credentials available to the user, and follow-on movement from privileged administrative workstations.

How an attack unfolds

An attacker first needs a way to influence content that Vim will evaluate, such as a malicious Vim script, plugin, filetype helper, session file, project configuration, or social-engineered instructions that lead a user to execute a crafted glob() expression. The attacker embeds a newline character inside the glob pattern so that, when Vim invokes shell-based expansion according to the user's 'shell' setting, the pattern is split in a way that permits an additional shell command. The victim must open, source, or otherwise trigger the malicious content in Vim. If triggered on a vulnerable Unix-like version, the injected command runs as the current user, allowing the attacker to read or change files available to that account, drop scripts, execute network tools, or modify shell/editor startup files for persistence. Exploitation is less likely to be fully remote by itself, but it is useful in phishing, malicious repository, supply-chain, and developer-workstation compromise scenarios.

How to fix it

Upgrade Vim to version 9.2.0202 or later on all Unix-like systems. Where distribution packages backport fixes, install the vendor-provided fixed package even if the displayed upstream version differs, and verify that the package changelog includes the patch for this issue. Prioritize systems where Vim is used to edit untrusted files, developer workstations, CI/build hosts, servers accessed by administrators, and shared multi-user Unix systems. As temporary mitigations, avoid sourcing untrusted Vim scripts or plugins, disable or tightly control project-local editor configuration, review filetype/plugin automation that calls glob() on untrusted input, and avoid workflows where users paste or execute Vim commands from untrusted sources. Restrict outbound network access and credential exposure for developer and administrative shells to reduce post-exploitation impact.

How to confirm the fix worked

Confirm remediation by checking that the installed Vim version is 9.2.0202 or later, or that the operating system vendor package contains the backported fix. Use commands such as 'vim --version' and the platform package manager to verify installed package versions across endpoints and servers. Inventory Unix-like systems for Vim, gVim, vim-enhanced, vim-minimal, and related packages because multiple package names may contain the vulnerable code. Validate that user-managed plugin directories and shared Vim configuration repositories do not contain suspicious glob() calls using newline-controllable input. For exposure testing, use a safe non-destructive proof of concept in an isolated environment only, confirming that a crafted glob() pattern with an embedded newline cannot cause shell command execution after patching.

Typical attack path

1. Identify a target likely to use Vim on a Unix-like system, such as a developer, administrator, or build user.
2. Prepare a malicious Vim-related artifact that causes Vim to evaluate glob() with an embedded newline in the pattern.
3. Deliver the artifact through a repository, plugin, shared configuration, archive, support instructions, or other user-driven workflow.
4. Convince or wait for the user to open, source, or execute the malicious Vim content.
5. Rely on Vim's vulnerable glob() handling and the user's configured shell to interpret the newline-separated payload as a command.
6. Execute arbitrary commands as the Vim user.
7. Use the resulting access to read sensitive files, alter code or configuration, drop persistence, or stage additional tooling.

How to detect it

Look for evidence that Vim or related editor binaries spawned a shell or command interpreter unexpectedly. Primary telemetry sources include endpoint detection and response process trees, Linux auditd execve records, Sysmon for Linux events, shell history, sudo logs, terminal session recording, file integrity monitoring, and network proxy/DNS logs from developer or administrative hosts. Focus on process ancestry where vim, gvim, view, ex, rvim, vimdiff, or editor-wrapper scripts launch /bin/sh, bash, dash, zsh, curl, wget, python, perl, nc, ssh, chmod, or persistence-modifying commands. Review recently added or modified Vim plugins, .vimrc files, .gvimrc files, after/ftplugin scripts, syntax scripts, session files, and repository-local editor configuration for glob() calls containing newline-controlled input. Investigate any suspicious child process followed by outbound network activity, credential file access, changes to shell startup files, modifications to source repositories, or creation of hidden files under user home directories. Because exploitation requires local user interaction and may leave no unique network signature, detection should emphasize endpoint process ancestry, script/configuration review, and correlation with untrusted repositories or files opened in Vim.

• vim spawning /bin/sh
• vim spawning /bin/bash
• vim spawning /bin/dash
• vim spawning /bin/zsh
• gvim spawning /bin/sh
• vimdiff spawning /bin/sh
• view spawning /bin/sh
• ex spawning /bin/sh
• parent_process_name=vim process_name=sh
• parent_process_name=vim process_name=bash
• parent_process_name=gvim process_name=sh
• parent_process_name=vimdiff process_name=sh
• parent_process_name=vim process_name=curl
• parent_process_name=vim process_name=wget
• parent_process_name=vim process_name=nc
• parent_process_name=vim process_name=python
• parent_process_name=vim process_name=python3
• glob("
• glob('
• ~/.vimrc
• ~/.gvimrc
• ~/.vim/plugin/
• ~/.vim/after/
• ~/.vim/ftplugin/
• ~/.vim/syntax/
• ~/.vim/sessions/
• ~/.config/vim/
• /etc/vim/vimrc
• /usr/share/vim/vimfiles/plugin/
• /usr/share/vim/vimfiles/ftplugin/

What your security team should do

• Patch Vim to 9.2.0202 or the vendor-fixed equivalent across Unix-like endpoints, servers, build images, containers, and administrative hosts.
• Prioritize developer workstations, CI/build systems, privileged administration hosts, and shared Unix servers because compromise of those systems has high downstream impact.
• Search managed configuration repositories, dotfile repositories, Vim plugin directories, and project templates for glob() usage that may process untrusted patterns.
• Harden editor workflows by limiting untrusted plugins, project-local configuration, and instructions that require users to source arbitrary Vim scripts.
• Add detection for shell processes spawned by Vim-family processes, especially when followed by network connections, file downloads, credential access, or startup-file modification.
• Review recent endpoint telemetry for suspicious Vim child processes or command execution if users opened untrusted repositories, archives, or editor plugins.
• Update base images and golden workstation/server templates so vulnerable Vim packages are not reintroduced.
• Because this is not currently KEV-listed, has low EPSS, and has no reported public exploit maturity, treat it as priority patching for high-value Unix workflows rather than an internet-wide emergency.