CVE-2026-52858

What it actually does

Vim versions prior to 9.2.0561 can execute attacker-controlled Python code when Python omni-completion is invoked on a hostile Python buffer. The vulnerable completion scripts, python3complete.vim for +python3 builds and pythoncomplete.vim for legacy +python builds, inspect import and from statements in the current file by using Python's import machinery. Because the buffer's working directory is included in sys.path, a malicious file can reference a sibling module or package whose top-level Python code runs during completion. Successful exploitation results in code execution inside the Vim process with the privileges of the user editing the file.

Why it matters to the business

This issue can turn routine editing of a downloaded or shared Python file into code execution on a developer or administrator workstation. Impact may include theft of source code, credentials, SSH keys, cloud tokens, package publishing credentials, or modification of local project files. Exploitation requires user interaction and a Vim build with Python support, and the current EPSS is low with no KEV listing or known ransomware association, but Vim is widely used in development and operations workflows, so exposed endpoints should still be patched promptly.

How an attack unfolds

An attacker prepares a Python file containing import or from statements that reference a module or package placed alongside the file. That sibling module contains malicious top-level Python code. The attacker then convinces a user to open the file in a vulnerable Vim build that has +python3 or legacy +python support enabled. When the user invokes Python omni-completion, for example while editing code, Vim's completion script attempts to resolve the imports in the buffer. Because the file's working directory is available to Python import resolution, the attacker's sibling module is imported and its top-level code executes as the editing user. The code can then read local files, exfiltrate secrets, modify project content, install persistence, or launch follow-on commands depending on local permissions and endpoint controls.

How to fix it

Upgrade Vim to version 9.2.0561 or later wherever Python editing is performed. If vendor packages backport patches, use the vendor-fixed package even if the displayed upstream version differs, and confirm the package changelog includes the python3complete.vim/pythoncomplete.vim fix. As interim mitigations, disable Python omni-completion for untrusted files, avoid opening untrusted source archives directly, remove or disable +python3/+python-enabled Vim builds where not required, use a sandboxed editor/container for reviewing untrusted Python projects, and enforce endpoint controls that restrict Vim from spawning shells or making network connections.

How to confirm the fix worked

Confirm the installed Vim build is patched by checking `vim --version` or `:version` and verifying it is 9.2.0561 or later, or that the OS/distribution package includes the backported fix. Check whether the build has Python interpreter support with `vim --version` or `:echo has('python3')` and `:echo has('python')`; systems without +python3/+python are not exposed to this specific execution path. Validate configuration does not force Python omni-completion for untrusted files. For high-assurance validation, perform testing only in an isolated disposable environment using a benign module that logs execution, then confirm omni-completion no longer imports and executes sibling package top-level code.

Typical attack path

1. Attacker creates a malicious Python project or archive containing a .py file and a sibling module or package with malicious top-level code.
2. The visible .py file includes import or from statements referencing the malicious sibling module or package.
3. Attacker delivers the project through phishing, source-code sharing, a pull request, a ticket attachment, chat, or another file-transfer channel.
4. Victim opens the Python file in Vim prior to version 9.2.0561 with +python3 or +python enabled.
5. Victim invokes Python omni-completion, such as insert-mode omni-complete for Python code.
6. Vim's Python completion script imports the referenced module using Python import machinery.
7. The attacker's module executes inside the Vim process with the victim user's privileges.
8. Attacker code performs post-exploitation actions such as credential discovery, source-code access, network callbacks, command execution, or persistence.

How to detect it

Because exploitation runs attacker Python code inside the Vim process, there may be no dedicated application log entry. Use endpoint telemetry, EDR, shell history, process creation logs, file modification events, and network logs to look for suspicious activity initiated by Vim after opening Python files. Key behaviors include Vim spawning `/bin/sh`, `bash`, `zsh`, `python`, `python3`, `curl`, `wget`, `ssh`, `nc`, `chmod`, `osascript`, or PowerShell; Vim making outbound network connections; unexpected writes to shell startup files, SSH authorized_keys, cron directories, systemd user units, LaunchAgents, or project files; and access to sensitive credential locations such as SSH keys, cloud credentials, Git credentials, package-manager tokens, or browser/session stores. Correlate these events with recent downloads, archives, pull-request checkouts, or external Python project directories. Also search for vulnerable Vim versions with +python3/+python support to identify systems where retrospective hunting is warranted.

What your security team should do

• Patch or update Vim to 9.2.0561 or a vendor-backported fixed package on developer workstations, build systems, jump hosts, and administrator endpoints.
• Prioritize systems where users review external code, handle pull requests, process ticket attachments, or maintain production credentials locally.
• Inventory Vim builds for +python3 or +python support and treat those below the fixed version as exposed.
• Temporarily disable Python omni-completion or require sandboxed review workflows for untrusted Python projects until patching is complete.
• Create EDR detections for Vim unexpectedly spawning shells, interpreters, download utilities, credential-access tooling, or initiating outbound network connections.
• Review recent endpoint telemetry for suspicious child processes or network activity originating from Vim around the time users opened external Python files.
• Educate developers that editor features such as autocomplete can execute project code and that untrusted source archives should be reviewed in isolated environments.