CVE-2026-57451

What it actually does

Vim versions prior to 9.2.0670 can read beyond the end of an internal line buffer when processing text properties from malformed undo data. The vulnerable code trusts an inline 16-bit text property count and treats it as the number of 32-byte textprop_T records present, but it does not verify that the line buffer actually contains that many records. A crafted undo file can therefore cause out-of-bounds reads when Vim loads or processes the line, resulting primarily in a crash and potential disclosure of adjacent process memory contents in crash artifacts or error behavior. The issue requires local file interaction and user action, such as opening a file in a context where the malicious undo file is loaded.

Why it matters to the business

The most likely consequence is disruption of developer, administrator, or automation workflows that rely on Vim, because opening an affected file with a crafted undo file can crash the editor. In sensitive environments, crash dumps or diagnostic logs could also expose small amounts of memory from the Vim process. The vulnerability is not listed in CISA KEV, has no known ransomware association, and has very low EPSS probability at this time, so broad internet-scale exploitation is unlikely; however, Vim is widely installed on servers, workstations, development containers, and administrative systems, making patching important as part of routine endpoint and base-image hygiene.

How an attack unfolds

An attacker prepares a Vim undo file containing malformed line text-property metadata: the line declares a large text-property count but does not include the corresponding amount of text-property data. The attacker then places or delivers that undo file alongside a file the target is likely to open, or convinces the target to work in a directory where Vim will discover and load the crafted undo state. When a vulnerable Vim version processes the undo file, it calls the affected text-property handling logic, trusts the embedded count, and reads past the end of the line buffer. The usual observable result is a Vim crash, often a segmentation fault or abnormal termination. Successful exploitation depends on user interaction and on Vim loading the malicious undo data; there is no indication from the provided intelligence of active exploitation, public exploit maturity, KEV listing, or ransomware use.

How to fix it

Upgrade Vim to version 9.2.0670 or later. Where Vim is supplied by an operating-system vendor or package repository, apply the vendor security update that backports the fix, even if the displayed upstream version differs. Rebuild base images, development containers, administrative jump hosts, and golden workstation images that include vulnerable Vim builds. As a temporary mitigation, avoid opening files from untrusted archives or directories where Vim undo files may be present, disable persistent undo for untrusted workspaces, and remove untrusted Vim undo files before editing. Temporary mitigations should not replace upgrading because the flaw is in Vim's parsing of undo/text-property data.

How to confirm the fix worked

Confirm the installed Vim version is 9.2.0670 or later, or confirm through the operating-system package changelog that the fix for this issue has been backported. Run `vim --version` and compare against the remediated package version supplied by the relevant vendor. Inventory endpoints, servers, containers, CI images, and developer workstations for Vim installations, including alternate binaries such as `vim`, `vim.basic`, `vim.gtk`, `vim.nox`, or distribution-specific variants. Validate that persistent undo directories do not contain untrusted undo files in shared, downloaded, or externally supplied project directories. After patching, opening previously suspicious files should no longer crash Vim due to malformed text-property counts.

Typical attack path

1. Identify a target likely to use Vim versions earlier than 9.2.0670 with persistent undo files enabled or with access to an attacker-supplied undo file.
2. Create or obtain a malformed Vim undo file containing an inflated text-property count with insufficient following text-property data.
3. Deliver the crafted undo file with a lure file, source archive, shared workspace, repository, removable media, or other file-transfer path.
4. Induce the user to open or edit the associated file using vulnerable Vim.
5. Vim loads or processes the crafted undo data and performs an out-of-bounds read while handling text properties.
6. The Vim process crashes, potentially interrupting work and creating logs or crash artifacts that may contain limited process-memory information.

How to detect it

Look for evidence of Vim crashing after opening files from untrusted or newly extracted directories. Useful sources include Linux system journals, syslog, audit logs, endpoint detection telemetry, crash reporters, core dump metadata, shell history, file creation telemetry, and file-integrity monitoring for Vim undo files. Investigate events showing `vim` or related binaries terminating with SIGSEGV, segmentation fault, bus error, or abnormal core dump creation, especially when accompanied by recently created or externally sourced undo files. On Linux systems using systemd-coredump, review `coredumpctl` entries for Vim crashes and correlate the working directory, command line, and timestamps with downloads, repository checkouts, archive extraction, email attachments, or removable media. In EDR telemetry, look for Vim opening files in directories that also contain Vim undo artifacts, followed by an immediate crash. Because exploitation is expected to be local and user-assisted and no active exploitation is reported, detection should focus on suspicious crash patterns and untrusted undo-file presence rather than network indicators.

• Vim: Caught deadly signal SEGV
• Segmentation fault (core dumped)
• segfault at
• comm="vim"
• exe="/usr/bin/vim"
• systemd-coredump
• Process vim dumped core
• vim.core
• core.vim
• *.un~
• .*.un~

What your security team should do

• Patch Vim to 9.2.0670 or the vendor-fixed package across workstations, servers, containers, and administrative images.
• Prioritize systems used by developers, system administrators, build engineers, and operators who frequently open external files, repositories, support bundles, or archives.
• Search for repeated Vim crashes, segmentation faults, or core dumps temporally associated with opening downloaded or externally supplied files.
• Review shared project directories, extracted archives, and unusual workspace locations for Vim undo files that arrived from external sources rather than being generated locally.
• If suspicious crashes are found, preserve the associated file, undo file, shell history context, crash dump metadata, and relevant system logs for forensic review.
• Disable or restrict persistent undo in high-risk workflows that handle untrusted files until patched.
• Monitor vendor advisories and package repositories for backported fixes because distribution package versions may not match the upstream Vim version exactly.