CVE-2026-52860

What it actually does

Vim versions before 9.2.0597 can execute attacker-controlled Python expressions when Python omni-completion is invoked on a hostile buffer. The completion engine reconstructs Python function and class definitions from the current file and evaluates them with exec() while building completion metadata. In Python, default argument values, type annotations, decorators, and class base expressions may be evaluated at definition time, so malicious code embedded in what appears to be normal Python source can run inside the Vim process. Execution occurs with the privileges of the user running Vim and can lead to command execution, file access, credential theft, or additional payload execution. The prior g:pythoncomplete_allow_import mitigation does not fully address this issue because exploitation does not require harvested import/from statements.

Why it matters to the business

A malicious Python file can compromise a developer or administrator workstation if opened in a vulnerable Vim version and omni-completion is triggered manually or by editor configuration. Successful exploitation can expose source code, SSH keys, cloud credentials, local secrets, and other files accessible to the user, and may provide a foothold into software development or operations environments. The issue is not currently in the CISA KEV catalog, has low EPSS, and has no reported mature public exploitation, but the operational risk is meaningful where Vim is widely used for code review, development, automation, or privileged system administration.

How an attack unfolds

An attacker prepares a Python source file containing malicious expressions in locations that Python evaluates during definition, such as default parameter values, annotations, decorators, or class inheritance expressions. The attacker then convinces a user to open the file in a vulnerable Vim release, for example through a repository, patch, attachment, support bundle, or copied code sample. When the user triggers Python omni-completion, or when an editor plugin/configuration triggers it automatically, Vim's Python completion logic reconstructs definitions from the buffer and passes them to exec(). The malicious expression executes in the context of the Vim process, allowing the attacker to run local commands, read files, launch child processes, or stage further payloads under the user's permissions.

How to fix it

Upgrade Vim to version 9.2.0597 or later wherever Python omni-completion may be used. If packages are supplied by an operating system or distribution vendor, apply the vendor security update that backports the fix even if the displayed upstream version differs. Where immediate upgrade is not possible, disable Python omni-completion for untrusted files, avoid triggering omni-completion on untrusted Python buffers, and review Vim/plugin configurations that automatically invoke omni-completion. Do not rely on g:pythoncomplete_allow_import as a complete mitigation for this flaw. Consider hardening developer workstations with endpoint controls that restrict editor-spawned shells, scripting interpreters, and unexpected network egress.

How to confirm the fix worked

Confirm the installed Vim build is patched by checking that it is version 9.2.0597 or later, or that the relevant vendor package changelog includes the backported fix for this vulnerability. Inventory systems with commands such as `vim --version`, package-manager queries, or endpoint software inventory. Validate editor configuration by confirming Python omni-completion is not automatically triggered on untrusted files where upgrades are pending. In a controlled non-production test environment, use a harmless marker-creating Python definition-time expression to confirm that triggering omni-completion no longer evaluates reconstructed buffer definitions. Also verify that endpoint controls generate alerts when Vim unexpectedly launches shells, Python interpreters, curl, wget, PowerShell, or other child processes.

Typical attack path

1. Attacker creates or modifies a Python file with malicious code embedded in definition-time expressions rather than obvious top-level executable code.
2. Attacker delivers the file through a source repository, pull request, email attachment, issue tracker, shared archive, or copied code snippet.
3. Victim opens the file in Vim version earlier than 9.2.0597.
4. Victim triggers Python omni-completion, such as with Ctrl-X Ctrl-O, or an installed completion plugin/configuration triggers completion automatically.
5. Vim reconstructs Python definitions and evaluates them with exec() while generating completion candidates.
6. Attacker-controlled Python expression executes inside the Vim process with the victim user's privileges.
7. Payload performs local actions such as spawning a shell, downloading a second stage, reading credentials, modifying files, or establishing outbound network connectivity.

How to detect it

There is usually no native Vim audit log showing that omni-completion executed malicious Python, so detection should focus on endpoint telemetry, shell history, file artifacts, and process/network behavior around Vim sessions. Review EDR process trees for vim, gvim, view, or related editor binaries spawning unexpected child processes such as sh, bash, zsh, cmd, powershell, python, perl, ruby, node, curl, wget, nc, ncat, socat, ssh, or openssl. Correlate those events with recent opening or editing of Python files from untrusted repositories, archives, email attachments, issue trackers, or temporary directories. Inspect shell histories, terminal scrollback, command audit logs, macOS Unified Logs, Linux auditd, Sysmon, Windows Event Logs, and network proxy/DNS logs for commands or outbound connections initiated by editor processes. Examine Vim swap, undo, backup, and session files for suspicious Python constructs in default arguments, annotations, decorators, or class base expressions. Look for payload artifacts such as newly created scripts in temporary directories, persistence changes in shell profiles or Vim configuration, unexpected credential access, and downloads executed shortly after a Vim process opened a Python file.

• vim -> sh
• vim -> bash
• vim -> zsh
• vim -> python
• vim -> python3
• vim -> perl
• vim -> ruby
• vim -> node
• vim -> curl
• vim -> wget
• vim -> nc
• vim -> ncat
• vim -> socat
• vim -> ssh
• gvim -> sh
• gvim -> bash
• gvim -> python
• gvim -> python3
• view -> sh
• view -> bash
• view -> python
• view -> python3
• pythoncomplete#Complete
• omnifunc=pythoncomplete#Complete
• setlocal omnifunc=pythoncomplete#Complete
• .swp
• .swo
• .un~
• .viminfo
• CommandLine contains "vim" AND CommandLine contains ".py"
• ParentImage contains "vim" AND Image contains "curl"
• ParentImage contains "vim" AND Image contains "wget"
• ParentImage contains "vim" AND Image contains "bash"
• ParentImage contains "vim" AND Image contains "sh"
• ParentImage contains "gvim" AND Image contains "python"

What your security team should do

• Prioritize upgrading Vim to 9.2.0597 or a vendor-patched equivalent on developer workstations, build hosts, administrator jump boxes, and systems where Vim is used to inspect untrusted Python code.
• Temporarily disable or restrict Python omni-completion and completion plugins that automatically evaluate Python buffers until patched.
• Hunt for suspicious process trees where vim, gvim, or view spawned shells, scripting interpreters, download utilities, or network tools.
• Warn developers and administrators not to trigger completion on untrusted Python files from pull requests, archives, tickets, or external sources until patched.
• Add EDR/SIEM detections for editor-originated command execution and unexpected outbound network connections from Vim processes.
• Review recent handling of untrusted Python files where users reported abnormal editor behavior, unexpected prompts, or terminal/network activity.
• Treat exposed credentials on systems with suspected exploitation as potentially compromised and rotate them after containment.