Vim CVE-2026-57451

Exploitation requires all of the following: (1) the target Vim binary must be compiled with +persistent_undo support (CheckFeature persistent_undo guards the test); (2) the 'undofile' option must be set, or the user must manually execute ':rundo <crafted_file>'; (3) at least one text property must exist in the buffer (b_has_textprop flag set) so that get_text_props() does not return early before reaching the malicious count; and (4) the attacker must deliver a precisely crafted binary undo file to a location Vim will load. Limiting factors: purely local attack vector (AV:L), mandatory user interaction to trigger the undo-file load (UI:R), and high attack complexity from the required binary-level crafting of the undo blob (AC:H). Remote unauthenticated exploitation is not possible.

The NVD CVSS 3.1 score of 5.3 (Medium) with vector AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:H correctly characterises a local, user-interaction-dependent, high-complexity attack. The high availability impact (crash) is the dominant risk signal; the low confidentiality impact reflects that the OOB read may expose adjacent heap bytes but does not guarantee controlled disclosure. No EPSS score was supplied in the input data, so exploitation probability cannot be quantified numerically. There is no KEV listing and no independent POC repository referenced - the closest artefact is the in-patch test function Test_textprop_undo_bad_prop_count, which demonstrates the binary manipulation but is not a standalone exploit. The CVSS PR:N rating is technically consistent with not requiring elevated OS privileges to place a file in a directory, though an attacker still needs a social-engineering path to get the victim to load the file. Overall this is a low-priority issue for most organisations; elevated priority only for environments where users routinely open Vim undo files from untrusted sources.

An attacker places a crafted .un~ undo file (with prop_count=0xFFFF encoded as two bytes while carrying only ~34 bytes of actual property data) in a project directory, then persuades a developer to open that directory in Vim with persistent undo enabled. On opening any previously edited file, Vim auto-loads the undo file, restores the malicious line, and when a subsequent text-property consumer (such as prop_list()) traverses the inflated count, it reads far past the line buffer, crashing Vim and potentially leaking heap contents. The in-patch test Test_textprop_undo_bad_prop_count demonstrates the exact binary substitution required.