CVE-2026-73074

Executive Summary

CVE-2026-73074 is an integer-overflow/wraparound vulnerability (CWE-190) in Vim's text-property handling logic, affecting all builds prior to version 9.2.0841. A crafted file or scripted Vim session that drives the property count past 0xffff causes an undersized heap allocation followed by an out-of-bounds copy of existing text-property records, leading to heap corruption, denial of service, and potentially arbitrary code execution in the context of the user running Vim. No public PoC or in-the-wild exploitation is currently known, and no CVSS score has been assigned; the issue is fixed in Vim 9.2.0841, though patch confidence is low (2/4) and at least one OSV package entry still lists the issue as unfixed.

Technical Analysis

Vim is an open-source command-line text editor deployed across virtually every Unix-like environment, including developer workstations, Linux servers, container images, and CI pipelines. The flaw resides in the text-property subsystem, an optional feature used by plugins and syntax engines to attach metadata (highlighting, decorations, etc.) to byte ranges within a buffer.

Based strictly on the NVD description, the affected code path is as follows:

1. When a new text property is added, the function prop_add_one() in src/textprop.c is invoked.
2. The helper function get_text_props() returns a value, proplen, which reflects the length/quantity of existing text-property records associated with the buffer or position being modified.
3. prop_add_one() uses the proplen value to increment a property count that is stored as a uint16_t. A uint16_t has a maximum representable value of 0xffff (65,535).
4. If the count is at or near that ceiling, the increment overflows and wraps to zero — the classic CWE-190 integer overflow/wraparound condition.
5. The code subsequently performs a heap allocation whose size is derived from the (now wrapped/zeroed) count, i.e., a buffer sized for none of the existing property records, and then copies the existing text-property records into that undersized allocation. This produces a heap buffer overflow — an out-of-bounds write with attacker-influenced record data.

The root cause is the absence of an upper-bound validation on the property count before the increment and before the allocation-size computation. The count field itself is deliberately compact (16-bit), but the code does not guard against reaching its limit.

Attack surface considerations:

• The affected component is reachable whenever Vim processes a buffer that has text properties attached. This is common in practice: syntax highlighting, plugin-driven annotation, and scripted editing (vim -es, vim -c, -S session scripts) can all create large numbers of properties.
• A malicious actor does not need to directly invoke prop_add_one(); they need only cause a Vim session to add more than 65,535 properties to a single list. This could plausibly be achieved with a crafted file that is subsequently opened with property-generating plugins (e.g., a large generated file that yields enormous numbers of highlight spans), or via a malicious Vim script loaded from a project directory (.vimrc, ftplugin, etc.).
• The advisory does not specify the exact minimum number of properties, the precise heap-record layout, or the file format necessary to trigger the bug deterministically. Consequently, exploitability depends on heap-layout control, which an attacker would need to develop empirically.

The vulnerability is fixed in version 9.2.0841. The OSV package entry (/, range 0→unfixed) indicates that, as of this writing, at least one distribution/package feed has not yet published a patched build — a meaningful operational detail for teams that rely on distro-packaged Vim rather than upstream builds.

Exploitation Scenarios

No public PoC or exploit code is known for CVE-2026-73074, and the vulnerability is not on the CISA KEV list. The attack chain below is therefore inferred from the vulnerability class (integer overflow → undersized heap allocation → out-of-bounds copy), not from a verified exploit.

1. Reconnaissance / target identification. The attacker selects an environment where a vulnerable Vim (< 9.2.0841) is used to open untrusted files. Typical targets include developer workstations, sysadmin jump hosts, and CI runners that invoke Vim for batch text processing. Delivery vectors include phishing attachments (.txt, .log, .conf), malicious files planted in repositories, or archives processed with automated Vim-based tooling.

2. Triggering the flaw. The victim opens the crafted file in Vim (vim file.txt) or a project hook sources a malicious Vim script. During processing, text properties are added to the buffer until the uint16_t property count is incremented beyond 0xffff. Because prop_add_one() uses the value from get_text_props() to increment without an upper-bound check, the count wraps to zero, and the code allocates a heap buffer sized for zero existing records.

3. Payload / execution method. Existing text-property records are then copied into the undersized buffer. This is an out-of-bounds heap write. An attacker who can control the number, size, and content of property records — and who has knowledge of the target's allocator behavior — can overwrite adjacent heap metadata or neighboring objects. In a best case for the attacker, this yields an arbitrary write primitive and, ultimately, code execution inside the Vim process. At minimum, it produces a crash (heap corruption detected by glibc, SIGABRT, or SIGSEGV).

4. Post-exploitation impact. Vim runs with the privileges of the invoking user. If a victim used sudo vim to edit a system file, code execution is obtained with root privileges. Even at user privilege, Vim exposes a full command environment (:terminal, :shell, :!), so a compromised Vim session effectively grants interactive shell access to the host. In CI pipelines, code execution in a Vim-based build step can lead to supply-chain compromise of produced artifacts. If the target is a shared host with other session, lateral movement becomes possible.

Impact Assessment

• Business impact. Memory-corruption vulnerabilities in ubiquitous developer tools carry outsize risk because they sit on the trust boundary between untrusted input (email attachments, cloned repositories, downloaded configs) and privileged user sessions. Successful exploitation yields code execution with the privileges of the developer, CI service account, or root if Vim was elevated.
• Affected systems. All Vim versions prior to 9.2.0841. This includes the default Vim builds shipped in most enterprise Linux distributions, many BSD systems, and numerous container base images. The OSV record currently shows a package state of 0→unfixed, meaning patched packages may not yet be available everywhere.
• Blast radius. Local, single-process at the point of exploitation, but the downstream blast radius includes any system or service reachable from the compromised account: source repositories, SSH keys, cloud credentials (e.g., in ~/.aws), and CI/CD secrets.
• CVSS. N/A — no vector or score has been published. EPSS is 0.00108 (1.4th percentile), indicating a very low modeled probability of exploitation in the wild at the time of writing. CISA KEV does not list this CVE, and no known threat-actor campaigns reference it.
• Integrity/confidentiality/availability. The flaw enables heap corruption: availability is trivially impacted (crash), while integrity and confidentiality are at risk if an attacker achieves the code-execution outcome. Until a public PoC exists, the practical maximum is a remote-triggered denial of service in contexts where Vim processes untrusted files automatically.

Detection Guidance

The following detection content targets the observable effects of CVE-2026-73074: (a) execution of vulnerable Vim builds, (b) Vim crash patterns consistent with heap corruption (SIGSEGV/SIGABRT), and (c) delivery of suspicious text artifacts that may serve as the malicious input. Because exploitation is local, network detection is heuristic and should be treated as supplementary.

Sigma Rule

title: Vim Heap Corruption Crash Indicator (CVE-2026-73074)
id: 3f8b42c6-9a21-4e7b-9d86-1f6a7b6b4c01
status: experimental
description: Detects termination of Vim processes with crash signals consistent with heap corruption caused by the CVE-2026-73074 textprop integer overflow (SIGSEGV=139, SIGABRT=134).
author: Valters IT Threat Intel
date: 2026/08/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-73074
logsource:
    product: linux
    category: process_termination
detection:
    selection_vim:
        Image|endswith:
            - '/vim'
            - '/vim.basic'
            - '/vim.tiny'
        ExitCode:
            - 134   # SIGABRT - glibc heap corruption / abort()
            - 139   # SIGSEGV - invalid memory access
    condition: selection_vim
falsepositives:
    - Non-exploit crashes in Vim or plugin code
    - Terminal multiplexers reporting child exit codes
level: medium
tags:
    - attack.execution
    - attack.t1203

YARA Rule

rule CVE_2026_73074_Vim_Source_Code_Artifact {
    meta:
        description = "Flags source checkouts or prebuilt artifacts containing the vulnerable Vim textprop code path (prop_add_one / get_text_props in src/textprop.c)."
        author = "Valters IT Threat Intel"
        date = "2026-08-01"
        cve = "CVE-2026-73074"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73074"
    strings:
        $fn1 = "prop_add_one" ascii
        $fn2 = "get_text_props" ascii
        $path = "src/textprop.c" ascii
    condition:
        uint16(0) == 0x457F and all of them
}

rule CVE_2026_73074_Vim_Vulnerable_Binary {
    meta:
        description = "Matches Vim ELF binaries whose embedded version string indicates a 9.2.x build prior to the 9.2.0841 fix."
        author = "Valters IT Threat Intel"
        date = "2026-08-01"
        cve = "CVE-2026-73074"
    strings:
        $vim = "VIM - Vi IMproved" ascii wide
        $ver92 = "9.2." ascii
        $patched = "9.2.0841" ascii
    condition:
        uint16(0) == 0x457F and $vim and $ver92 and not $patched
}

Suricata IDS Rule

# NOTE: CVE-2026-73074 requires local file processing; network detection is
# limited to identifying delivery of likely malicious text artifacts to hosts
# running Vim. Heuristic rule — expect noise, tune per environment.

alert http any any -> any any (msg:"CVE-2026-73074 Vim textprop - suspicious text artifact download (heuristic)"; flow:established,to_client; http.file_name; pcre:"/\.(txt|log|conf|md|vim|vimrc|gvimrc)$/i"; http.response_body; content:"|00 00 00 00|"; depth:1024; classtype:attempted-user; sid:20373074; rev:1; reference:cve,2026-73074;)

Elastic Detection

// EQL - detect Vim processes terminating abnormally (heap corruption signature)
process where event.category == "process" and
    event.action in ("end", "process_termination") and
    process.name in ("vim", "vim.basic", "vim.tiny") and
    process.exit_code in (132, 134, 139)

// EQL - detect invocation of known-vulnerable Vim while opening text-like files
process where event.category == "process" and
    event.action in ("exec", "execve", "fork") and
    process.name == "vim" and
    process.args in ("*.txt", "*.log", "*.conf", "*.md")

Splunk SPL Query

# Detection 1: Vim crashes consistent with heap corruption (auditd/syslog)
(index=linux OR index=endpoint) sourcetype=linux_audit
    (comm=vim OR exe IN ("*/vim", "*/vim.basic", "*/vim.tiny"))
    (sig=sigsegv OR sig=sigabrt OR exit_code=134 OR exit_code=139)
| stats count by host, exe, sig, _time
| sort - _time

# Detection 2: vulnerable Vim version execution inventory
index=endpoint process_name=vim
| eval vulnerable = if(process_version < "9.2.0841", "yes", "no")
| where vulnerable = "yes"
| stats count by host, process_name, process_version

Wazuh OSSEC Rule

<group name="vim,">
  <rule id="128977" level="12">
    <program_name>^vim|^kernel</program_name>
    <match>segfault|general protection fault|heap corruption|double free</match>
    <description>CVE-2026-73074 - Vim textprop heap corruption crash detected on $(hostname)</description>
    <group>pci_dss_11.4,gdpr_IV_35.7.d,</group>
  </rule>

  <rule id="128978" level="6">
    <program_name>^vim</program_name>
    <match>VIM - Vi IMproved 9\.2\.</match>
    <description>CVE-2026-73074 - Vim 9.2.x executed; verify patch level is >= 9.2.0841</description>
    <group>vulnerability,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 2/4 (CLAIMED) — the fix in version 9.2.0841 is reported by a single source (OSV) and has not been independently confirmed. The OSV package entry / currently shows the range 0→unfixed, meaning patched builds may not yet be propagated to all distribution feeds. Treat the fix as real but verify it against your own package mirror.

1. Immediate mitigations.

   • Do not open untrusted files (email attachments, downloaded archives, cloned repository files) in Vim on sensitive systems until patched.
   • When Vim must process untrusted input, launch it in a minimal, plugin-free configuration: vim -u NONE -i NONE -n — this reduces the attack surface by disabling the plugin/syntax logic most likely to generate large numbers of text properties.
   • Avoid running Vim with elevated privileges (sudo vim) for files that did not originate from a trusted source.
   • Confine Vim with an enforcement sandbox where available: AppArmor/SELinux profiles, or ideally run untrusted-editing tasks inside an ephemeral container or VM.
   • Because this is a memory-corruption issue in a widely deployed tool, apply the OS-level hardening benefit of ASLR and compiler fortification; rebuild Vim with -D_FORTIFY_SOURCE=2 if compiling from source.

2. Patch / upgrade steps.

   • Upgrade Vim to 9.2.0841 or later as soon as the package is available in your distribution's repository. If the distro feed lags (as the OSV 0→unfixed state suggests), install the upstream build or use a backported package from a trusted vendor channel.
   • Verify the installed version on every affected host: vim --version (check the first line, which contains the version number) or query package managers (e.g., dpkg -l vim, rpm -q vim, pacman -Q vim).
   • After patching, re-run the version check and inventory all systems that previously reported a version < 9.2.0841.
   • Monitor OSV (https://osv.dev) and the NVD entry for this CVE for updated package status and independent confirmations of the patch.

3. Long-term hardening.

   • Subscribe to Vim security advisories and to OSV/NVD feeds for all CLI developer tools; these tools are a persistent and under-monitored entry point for malware delivery.
   • Standardize Vim configuration across the enterprise (managed .vimrc, approved plugin allowlist) so that project-supplied Vim scripts cannot silently load.
   • Add crash-signal detection (the Sigma/Elastic/Splunk/Wazuh content above) to endpoint monitoring so that any future exploitation attempts are visible even without a public PoC.
   • Re-audit CI/CD pipelines: replace Vim-based text manipulation of untrusted artifacts with sandboxed utilities or containerized steps.
   • Treat the "no public PoC" status as temporary. The vulnerability class (heap overwrite via counter wraparound) is well understood and trivially exploitable by skilled adversaries once the trigger conditions are mapped; prioritize patching within the standard 30-day window for memory-corruption flaws even in the absence of an active exploit.

References

1. NVD — CVE-2026-73074: https://nvd.nist.gov/vuln/detail/CVE-2026-73074
2. OSV Advisory — CVE-2026-73074: https://osv.dev/vulnerability/CVE-2026-73074
3. Vim Project — official site & security information: https://www.vim.org/
4. CISA Known Exploited Vulnerabilities Catalog (KEV): https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CVE-2026-73074 is not listed.
5. MITRE ATT&CK — T1203 Exploitation for Client Execution: https://attack.mitre.org/techniques/T1203/

Threat-actor activity: No in-the-wild exploitation, public PoC, or known threat-actor campaign currently references CVE-2026-73074 as of the writing of this report. EPSS (0.00108, 1.4th percentile) corroborates a low immediate exploitation likelihood; however, the affected software's ubiquity and the vulnerability's memory-corruption class warrant proactive patching.