Vim CVE-2026-73074

Exploitation requires a local user to open a malicious file or execute a malicious Vim script that calls prop_add() more than 65,535 times on a single line - a condition only reachable through Vim's text-properties API (prop_add() / FEAT_PROP_POPUP). The CVSS 4.0 vector UI:A confirms active user interaction is required: the victim must open the crafted file or source the script. Attack complexity is rated AC:H, reflecting that triggering the counter wrap requires constructing a scenario with precisely more than 0xffff prop_add calls, which is non-trivial in typical document content but straightforward in a malicious Vimscript. Exploitation is NOT possible without user interaction with a crafted artifact. The flaw does not affect Vim builds compiled without FEAT_PROP_POPUP, though most modern distribution packages include this feature.

The CVSS 4.0 vector (AV:L/AC:H/PR:N/UI:A) correctly characterises this as a local, user-interaction-dependent flaw with high attack complexity, limiting opportunistic mass exploitation; the high C/I/A impact reflects that successful heap corruption in an editor process can yield code execution or information disclosure. EPSS data was not provided, but given the local vector, high complexity, and requirement to open a specially crafted file, real-world exploitation probability is likely low-to-moderate even for targeted attacks. There is no CISA KEV entry and no independent POC beyond the upstream regression test included in the fix commit. The absence of a KEV listing and the AC:H rating together suggest this is not currently being exploited at scale - a small or mid-sized IT team should patch on a normal vulnerability-management cycle rather than treating it as an emergency. The tags list 'Information Disclosure' alongside 'Integer Overflow', which is consistent with heap-content leakage being one possible exploitation outcome prior to full memory corruption.

An attacker crafts a file or Vim script that, when opened, triggers a loop adding more than 65,535 text properties to a single line via prop_add(). On the 65,536th call, the uint16_t counter wraps to zero, and Vim allocates a zero-sized heap block while copying the existing property array into it, corrupting the heap. Depending on allocator behaviour and surrounding heap layout, this can lead to information disclosure of heap contents or arbitrary code execution within the Vim process under the privileges of the opening user.