CVE-2026-35177

What it actually does

Vim versions prior to 9.2.0280 contain a path traversal bypass in the bundled zip.vim plugin. When a user opens a specially crafted ZIP archive in Vim, malicious archive paths can escape the intended archive-handling context and overwrite files that are writable by the user running Vim. The flaw does not directly disclose data or grant privileges by itself, but it can modify configuration files, scripts, source files, or other user-writable content, potentially affecting integrity and availability.

Why it matters to the business

An attacker could trick a developer, administrator, or other Vim user into opening a malicious ZIP file and cause local files to be overwritten. In practical terms, this can lead to corrupted work, tampered scripts or configuration files, persistence through modified shell/editor startup files, or disruption of development and operational workflows. The current EPSS is very low, there is no known KEV listing, no ransomware association, and no reported exploit maturity, but Vim is widely deployed and often used by technical staff, so patching should still be included in routine endpoint and server hardening.

How an attack unfolds

Exploitation requires user interaction. An attacker prepares a ZIP archive with crafted internal file paths designed to bypass Vim zip.vim path traversal protections. The attacker then delivers the archive through a plausible channel such as email, chat, source code exchange, issue attachments, or a shared repository. When the victim opens the archive with an affected Vim version, the zip.vim plugin processes the archive entries and may write outside the expected location. Any file writable by the victim account may be overwritten, such as editor configuration, shell startup files, scripts, project files, or other user-owned content. The attacker’s objective is typically to corrupt data, alter behavior of future tools or logins, or stage persistence that executes later when the modified file is used.

How to fix it

Upgrade Vim to version 9.2.0280 or later. Where Vim is supplied by an operating system package manager, install the vendor-provided security update and verify that the package includes the upstream fix even if the displayed version is backported. If immediate patching is not possible, reduce exposure by avoiding opening untrusted ZIP archives in Vim, using alternative archive inspection tools that safely validate paths, disabling or restricting use of the zip.vim plugin where operationally feasible, and handling untrusted archives inside a sandboxed or disposable environment with minimal file-system permissions.

How to confirm the fix worked

Confirm the installed Vim build is fixed by checking the runtime version and patch level with commands such as `vim --version` and verifying patch 9.2.0280 or a vendor backport that includes the fix. Inventory managed endpoints and servers for Vim packages older than the fixed build. Review the installed runtime plugin path for zip.vim and confirm it comes from an updated package. As a functional validation, safely test in a disposable sandbox with a non-sensitive directory and a benign traversal-style archive to confirm Vim no longer writes outside the expected archive-handling location. Also verify that endpoint management, golden images, containers, developer workstations, and administrative jump hosts are updated consistently.

Typical attack path

1. Identify targets likely to open ZIP archives with Vim, such as developers, system administrators, or support engineers.
2. Create a malicious ZIP archive containing traversal-style entry paths intended to escape Vim zip.vim archive handling.
3. Deliver the archive through social engineering, a shared project, ticket attachment, email, chat, or repository artifact.
4. Convince the user to open or inspect the ZIP archive in an affected Vim version prior to 9.2.0280.
5. Vim invokes zip.vim to browse or process the archive and writes attacker-controlled content to unintended user-writable paths.
6. The overwritten file causes disruption immediately or changes behavior later when a shell, editor, script, build process, or application consumes it.

How to detect it

There is typically no dedicated Vim security log for this issue, so detection depends on endpoint telemetry, file integrity monitoring, shell history, audit logs, EDR process/file events, and email or web download records. Look for users opening ZIP archives with vim or gvim shortly before unexpected changes to sensitive user-writable files. Prioritize investigation of modified shell startup files, Vim configuration, Git hooks, build scripts, cron entries, SSH authorized_keys, desktop autostart files, and frequently executed project scripts. In archive repositories, mail gateways, and attachment stores, search for ZIP entries containing traversal patterns such as `../`, `..\`, absolute Unix paths, Windows drive-letter paths, or paths targeting startup/configuration files. Correlate suspicious archive access with subsequent command execution, login behavior changes, or build/deployment anomalies. No public threat actors, KEV exploitation, or ransomware campaigns are currently associated with this vulnerability based on the provided intelligence.

• process_name=vim AND file_name=*.zip
• process_name=gvim AND file_name=*.zip
• ../
• ..\
• /etc/passwd
• /etc/cron.d/
• /etc/profile
• ~/.ssh/authorized_keys
• ~/.bashrc
• ~/.bash_profile
• ~/.profile
• ~/.zshrc
• ~/.vimrc
• .git/hooks/
• zip.vim

What your security team should do

• Prioritize upgrading Vim to 9.2.0280 or later across developer workstations, administrator systems, servers, containers, and base images where Vim is installed.
• Because the vulnerability requires user interaction and has low current exploitation likelihood, handle it through normal vulnerability management timelines unless Vim is heavily used to inspect untrusted archives.
• Issue user guidance advising staff not to open unexpected or untrusted ZIP archives directly in Vim until patched.
• Hunt for suspicious recent modifications to user startup files, editor configuration, scripts, cron entries, SSH authorized keys, and project files where the writing process was vim or gvim.
• Add EDR or audit coverage for archive-opening workflows where Vim writes to sensitive user-writable paths such as shell startup files or SSH configuration.
• Ensure phishing, ticketing, chat, and code-review attachment scanning treats ZIP files with traversal-style entry names as suspicious.
• Update hardened workstation and server images so newly provisioned systems do not reintroduce vulnerable Vim builds.