CVE-2026-57452

What it actually does

Vim versions prior to 9.2.0671 can crash when opening a specially crafted Vim-encrypted file using the VimCrypt~04! or VimCrypt~05! formats, which rely on xchacha20poly1305 through the +sodium feature. If the encrypted file body is shorter than the expected libsodium secretstream header, an unsigned length calculation underflows. Vim then passes an invalid, excessively large length to the decryption routine, causing an out-of-bounds read beyond the input buffer and terminating the Vim process. The impact is denial of service of the local Vim process; there is no indicated confidentiality or integrity impact and no known code execution.

Why it matters to the business

An attacker who can get a user or automated workflow to open a malicious encrypted Vim file can cause Vim to crash, potentially interrupting developer, administrator, or operational workflows and causing loss of unsaved editing state. The risk is moderate because exploitation requires a crafted local file to be opened by a user or process, the EPSS score is very low, there is no known public exploit maturity or CISA KEV listing, and the flaw is limited to availability of the editor process. Organizations with broad Vim deployment, developer workstations, administrative jump hosts, or scripts that invoke Vim on untrusted files should still patch during normal maintenance because the trigger is simple and reliable.

How an attack unfolds

An attacker creates a malformed Vim-encrypted file whose header advertises the VimCrypt~04! or VimCrypt~05! encryption method but whose encrypted payload is shorter than the libsodium secretstream header expected by Vim. The attacker then delivers the file through a channel where a victim may open it locally, such as a source repository, archive, shared file location, support attachment, or copied configuration bundle. When a vulnerable Vim build with +sodium support opens the file, Vim attempts to initialize decryption, performs an unsigned length calculation on the too-short body, underflows the length, and calls the decryption routine with a length that causes an out-of-bounds read. The Vim process crashes, denying service to the user or any automated task invoking Vim. Current intelligence does not indicate exploitation by named threat actors, ransomware use, or inclusion in the CISA Known Exploited Vulnerabilities catalog.

How to fix it

Upgrade Vim to version 9.2.0671 or later. Where Vim is provided by an operating system or distribution package, apply the vendor security update that backports the fix, even if the displayed upstream version appears older. If immediate patching is not possible, reduce exposure by avoiding opening untrusted Vim-encrypted files, blocking or quarantining unexpected files that begin with VimCrypt~04! or VimCrypt~05!, and using alternate viewers or sandboxed environments to inspect suspicious files. Systems built without Vim's +sodium feature are not expected to reach the vulnerable xchacha20poly1305 decryption path, but disabling features should be treated as a temporary mitigation rather than a substitute for applying the fixed version.

How to confirm the fix worked

Confirm remediation by checking that Vim reports version 9.2.0671 or later, or that the installed distribution package includes the vendor's backported fix. Use `vim --version` to verify the compiled feature set and determine whether `+sodium` is present. Validate package status with the relevant package manager, such as `dpkg -l vim`, `rpm -q vim`, `apk info vim`, `pacman -Qi vim`, or the platform's software inventory tooling. As a functional validation, opening a safely generated malformed test file with a VimCrypt~04! or VimCrypt~05! marker and a body shorter than the libsodium secretstream header should not crash the patched Vim process; perform this only in a disposable test environment. Also review crash reporting or endpoint telemetry after patching to confirm that Vim crashes associated with VimCrypt files have stopped.

Typical attack path

1. Identify users, repositories, shared locations, or workflows where Vim may be used to open externally supplied files.
2. Craft a file beginning with a VimCrypt~04! or VimCrypt~05! encrypted-file marker but with an encrypted body shorter than the required libsodium secretstream header.
3. Place or deliver the crafted file through a plausible channel such as an archive, repository, attachment, shared folder, or troubleshooting bundle.
4. Persuade or wait for a user or automated process to open the file with a vulnerable Vim build that includes +sodium support.
5. Trigger Vim's vulnerable decryption path, causing an out-of-bounds read and process crash.

How to detect it

Look for evidence of Vim process crashes shortly after opening small or unexpected files containing the VimCrypt~04! or VimCrypt~05! markers. Relevant log sources include Linux system journals, syslog, kernel logs, auditd process execution records, endpoint detection telemetry, application crash reporters, core dump managers such as systemd-coredump, shell history where available, file access telemetry, and repository or file-sharing audit logs. Search for Vim crashes with segmentation faults, aborts, bus errors, or core dumps where the command line references an encrypted or suspiciously small file. Examine recent files delivered through email, tickets, shared drives, archives, or source repositories for the VimCrypt~04!/VimCrypt~05! magic strings and an encrypted body shorter than 24 bytes after the VimCrypt marker. Forensic review should focus on whether the crash was induced by an externally supplied file, whether the same file was opened by multiple users, and whether any delivery channel shows deliberate placement. Because the expected impact is only a local denial of service, the most likely evidence is a Vim crash artifact rather than persistence, command execution, privilege escalation, or network beaconing.

• VimCrypt~04!
• VimCrypt~05!
• comm="vim"
• comm="vim.basic"
• comm="vim.gtk3"
• comm="gvim"
• segfault at
• Core dumped
• systemd-coredump
• Process vim dumped core
• vim crashed
• vim: Segmentation fault
• vim: Bus error
• signal 11
• SIGSEGV
• xchacha20poly1305
• libsodium

What your security team should do

• Patch Vim to 9.2.0671 or a vendor-fixed package across developer workstations, administrator systems, build hosts, and servers where Vim is installed.
• Prioritize systems where users regularly open files from external repositories, archives, tickets, email attachments, or shared file stores.
• Inventory Vim builds for `+sodium` support, because those builds are the most relevant to the vulnerable VimCrypt~04!/VimCrypt~05! code path.
• Add detection or content scanning for unexpected files containing `VimCrypt~04!` or `VimCrypt~05!`, especially when the file is unusually small.
• Review endpoint crash telemetry, system logs, and core dumps for recent Vim crashes correlated with encrypted Vim files.
• Educate users not to open unexpected encrypted Vim files from untrusted sources until patched.
• If patching is delayed, inspect suspicious encrypted files in a sandbox or isolated analysis VM rather than on production workstations.