CVE-2026-57452: Vim Encrypted File Underflow Denial of Service

Technical summary

The vulnerability stems from an unsigned integer underflow during the decryption process when Vim processes an encrypted file whose body is shorter than a single libsodium secretstream header. The secretstream header is a fixed-size structure required by the XChaCha20-Poly1305 AEAD construction. When the input buffer is too small, the length calculation underflows, resulting in an excessively large read operation that extends well past the legitimate buffer boundary. This out-of-bounds memory read triggers a crash (denial of service) in the decryption routine. The vulnerability is rooted in improper length validation before the decryption call, and affects only builds compiled with the +sodium feature.

Business impact

This is a local denial-of-service vulnerability with limited scope. An attacker cannot achieve code execution or data exfiltration; the only consequence is an abrupt crash of the Vim editor. The business impact depends on Vim's role in your environment. For organizations relying on Vim for critical scripting, automation, or system administration tasks, unexpected crashes could disrupt workflows. For development teams using Vim as a primary editor, a maliciously crafted encrypted file could be a nuisance vector. However, since exploitation requires local file system access and user interaction (opening the file), the risk is constrained to users who work with encrypted files, and the damage is limited to availability of the editor session, not data loss or system compromise.

Affected systems

Vim versions prior to 9.2.0671 are affected, but only if Vim was compiled with the +sodium feature enabled. The +sodium feature adds support for libsodium-based encryption (VimCrypt~04! and VimCrypt~05! methods). Distributions and builds that include this feature are at risk if users open specially crafted encrypted files. Many standard Vim builds on Linux distributions, macOS package managers, and Windows installers may include +sodium support; verify your installation with ':version' in Vim to check for the +sodium tag. Unaffected: Vim 9.2.0671 and later, Vim builds compiled without +sodium, and Vim instances not opening VimCrypt~04!/~05! encrypted files.

Exploitability

Exploitability is low due to multiple practical constraints. An attacker must have the ability to place a maliciously crafted encrypted file on the local file system where a Vim user will open it—requiring either local system access, file upload capabilities, or social engineering. The attack is not network-based, cannot be triggered by simply having the file present, and requires explicit user action (opening the file in Vim). There is no known public exploit code, and the vulnerability does not appear on the CISA Known Exploited Vulnerabilities list. The outcome is denial of service only (editor crash), not privilege escalation or data breach.

Remediation

Update Vim to version 9.2.0671 or later. For users unable to immediately patch, mitigation is straightforward: avoid opening untrusted or unknown encrypted files, or disable support for VimCrypt~04!/~05! encrypted files by compiling Vim without the +sodium feature (not practical for most users). Alternatively, inspect the file size and structure before opening if you suspect a malformed encrypted file. The recommended approach is to apply the patch, as Vim updates are typically low-friction and the fixed version addresses the root cause of the underflow.

Patch guidance

Verify your current Vim version using ':version' or 'vim --version' and check for the +sodium feature. If running version 9.2.0671 or later with +sodium, you are not affected. If running an earlier version with +sodium enabled, apply the update via your package manager (apt, brew, chocolatey, etc.) or by building from source. The patch is available in Vim's official repository. Test the patched version with any automation or scripts that depend on Vim to ensure compatibility. For organizations managing multiple systems, include Vim updates in your regular patch cycle; this is a MEDIUM-severity issue and should be prioritized after critical patches but ahead of low-severity items.

Detection guidance

Detection is challenging because this vulnerability only manifests when a specific condition is met: a Vim process with +sodium support opens a specially crafted encrypted file with a body smaller than the secretstream header. Endpoint detection strategies: (1) Monitor for unexpected Vim crashes or segmentation faults in logs, correlating them with recent file opens or encrypted file activity; (2) Hunt for unusual Vim invocations with encrypted file arguments (e.g., files named with .vim-crypt or custom extensions); (3) Use EDR tools to baseline Vim behavior and alert on abnormal terminations. (4) If you maintain Vim build standards, regularly audit systems to confirm Vim versions and feature flags. Network-based detection is not applicable. Log analysis of core dumps or syslog entries mentioning Vim crashes and file paths may help identify targeted attempts.

Why prioritize this

Prioritize this patch as MEDIUM-tier, below critical infrastructure and remote code execution flaws, but ahead of low-severity updates. Rationale: the CVSS score of 5.5 (MEDIUM) reflects limited impact (availability only, no confidentiality or integrity loss), local-only attack vector, and requirement for user interaction. It does not appear on the KEV list, indicating no active in-the-wild exploitation has been reported. However, any denial-of-service vulnerability affecting a widely-used tool like Vim warrants attention, especially in environments where Vim is part of critical automation or system administration workflows. Patch within 30–60 days as part of standard maintenance.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) reflects: Attack Vector = Local (requires file system access), Attack Complexity = Low (no special conditions beyond file size), Privileges Required = None, User Interaction = Required (user must open the file), Scope = Unchanged (only Vim process affected), and Impact = High Availability loss (crash). The lack of confidentiality or integrity impact and the prerequisite of local access keep the score moderate. The unsigned integer underflow (CWE-191) combined with out-of-bounds read (CWE-125) are well-understood vulnerability patterns, and the fix is straightforward, reducing long-term risk.

Frequently asked questions