CVE-2026-73074

CVE-2026-73074 is a heap buffer overflow in Vim's text property handling that stems from a semantic mismatch between allocation sizing and data copying, triggered when the property count wraps at uint16_t's 0xFFFF boundary. The vulnerability lives not in the increment operation itself—wrapping is defined C behavior—but in the gap between two subsystems that each reason locally but fail when composed: the allocation logic receives a wrapped-to-zero property count and allocates a zero-sized buffer, while the copy logic uses the original pre-wrap proplen to copy actual record data into that buffer. The result is heap corruption with execution potential, compounded by Vim's role in development workflows—CI pipelines, git hooks, remote servers, and scripted automation all process untrusted input through Vim daily. Prioritize three actions. First, verify your Vim version is 9.2.x and apply the patch to src/textprop.c immediately—this is not a theoretical edge case; it triggers with well under 65,536 text properties in a buffer, well within reach of complex documents or plugin-driven editing. Second, audit your deployment surface: any Vim invocation that processes untrusted files, runs in CI, or executes Vim scripts from untrusted sources is a potential exploitation vector. Third, scan your codebase for the pattern: uint16_t (or other bounded integer types) used to size heap allocations, where that value can be influenced by untrusted input. The fix likely adds a bounds check at the prop_add_one() API boundary, but the deeper remediation is recognizing that type ceilings are not runtime invariants—they are compile-time constraints that adversarial input can violate. UBSan would not have caught this because the wrapping is defined behavior; the failure mode lives in the composition gap, not the arithmetic operation. Treat type boundaries as hypotheses to validate at trust boundaries, not guarantees to assume.

Reviewed through automated stages and approved by a human before publication.