CVE-2026-73072

Executive Summary

CVE-2026-73072 is a heap-based buffer overflow (CWE-122) in Vim's spell file parser, affecting versions prior to 9.2.0846. A crafted spell file in which an SN_SAL section precedes an SN_SOFO section corrupts the sl_sal_first[] mapping list state inside set_sofo(), leading to under-counted mappings and attacker-influenced writes beyond a heap allocation. The primary risk is arbitrary code execution in the context of the user who opens the malicious file, most commonly achieved through social engineering that delivers a hostile .spl spell file to a Vim user with spell checking enabled.

Technical Analysis

The vulnerability resides in src/spellfile.c and is rooted in improper re-initialization of heap state between two related code paths: set_sal_first() and set_sofo().

During spell file loading, Vim parses a series of typed sections. The SN_SAL section defines a "sound-alike" phonetic mapping table, which set_sal_first() uses to populate the sl_sal_first[] array. The SN_SOFO section defines a "find original" (folding) mapping table, which set_sofo() subsequently processes. The flaw is that set_sofo() reuses the sl_sal_first[] buffer without first resetting values left behind by set_sal_first(). When a spell file presents an SN_SAL section followed by an SN_SOFO section, stale array entries persist and are interpreted as valid mapping-list metadata by set_sofo().

The consequence is described in the NVD advisory as: "under-counted mapping lists and attacker-influenced writes beyond a heap allocation." In practical terms:

1. The stale sl_sal_first[] values produce incorrect count/length bookkeeping for the SOFO mapping lists.
2. When Vim iterates these lists and writes mapping results, the count underestimation causes writes to advance past the end of the allocated heap object.
3. Because the attacker controls the spell file content and therefore the mapping entries, both the write offset and the written bytes are attacker-influenced, satisfying the CWE-122 (heap-based buffer overflow) classification.

The overflow occurs during a file-parsing operation and is triggered purely by file contents; no interactive command or special Vim configuration beyond spell checking is strictly required — the file must simply be consumed by the spell loader. The issue is fixed in Vim 9.2.0846 and no workaround has been published by the vendor. Note that no CVSS vector has been assigned, no affected-version range other than "prior to 9.2.0846" has been formally published, and the OSV entry currently lists the package state as unfixed with no version detail, so the full scope of vulnerable builds derived from the Vim source tree cannot be independently verified at this time.

Exploitation Scenarios

No public proof-of-concept or exploit code is known for CVE-2026-73072; the attack chain below is inferred from the vulnerability class and the precise mechanism disclosed in the NVD description.

1. Reconnaissance / target identification: An attacker identifies Vim users who process documents with spell checking enabled, or targets environments where Vim is the standard editor (developer workstations, Unix administration hosts, CI containers with Vim installed). Delivery is file-centric: the attacker must get the victim to load a crafted spell file, either by (a) sending a document accompanied by a malicious .spl file, (b) planting the .spl file in a spell directory that Vim scans (~/.vim/spell/ or the runtime path), or (c) bundling it inside a repository, tarball, or plugin that the victim voluntarily opens.

2. Flaw trigger: The spell file is crafted so that an SN_SAL section appears before an SN_SOFO section. When Vim parses the file, set_sal_first() populates sl_sal_first[], then set_sofo() is invoked and reuses the same array without clearing it. The poisoned file content produces the described count/mapping mismatch, which drives the heap write beyond the allocation boundary.

3. Payload / execution method (vulnerability-class level): The attacker influences an out-of-bounds heap write where both the write position and the written bytes derive from spell-file mapping data. In a standard heap-overflow exploitation flow, the attacker grooms the heap so the overwritten region contains security-sensitive objects (e.g., heap metadata, function pointers, or adjacent Vim data structures) and then corrupts one of them to redirect control flow. Given Vim's complexity, additional file sections and subsequent parser behavior provide plausible primitives for converting the write into code execution; however, the specific gadgets or structures used cannot be confirmed without a PoC and are out of scope for this report.

4. Post-exploitation impact: Successful exploitation yields code execution with the privileges of the Vim process — typically the logged-in user. Because Vim is frequently operated with elevated access on shared systems (sudo usage, root-owned editing sessions), privilege escalation may follow. Vim is also a common vector for persistence via vimrc/plugin tampering, and an editor compromise can be leveraged to inject malicious content into source code, configuration files, or commit hooks of the targeted user.

Detection caveat: since PoC status is UNKNOWN and no exploit is public, monitored "exploitation signals" in the wild are more likely to manifest as Vim crash events (segmentation faults, aborts) than as identifiable network payloads.

Impact Assessment

• Confidentiality / integrity / availability: A successful heap overflow can corrupt the Vim process memory, leading to either a crash (availability) or attacker-controlled execution (complete loss of confidentiality and integrity of the user's session and files). The impact is local, in the sense that the attacker must deliver a crafted file and convince the user to open it; there is no evidence of a network-reachable component in Vim itself.
• Affected systems: All Vim builds compiled from source trees prior to 9.2.0846. This includes Linux distributions, macOS, BSD, and Windows binaries that lag behind upstream. The OSV record currently marks the package as unfixed, indicating that downstream packaging (e.g., distro backports) may not yet carry the correction.
• Blast radius: Vim is one of the most widely deployed editors on Unix-like systems, and spell files are frequently synchronized across machines via dotfiles repositories. A single malicious .spl file could therefore affect an entire fleet of developer machines that share dotfiles. However, the practical risk is moderated by low exploitability evidence: EPSS score is 0.00125 (2.6th percentile), the CVE is not in CISA's Known Exploited Vulnerabilities catalog, no public PoC exists, and no CVSS score has been issued, which combined indicate low current threat activity.
• CVSS consideration: With CVSS vector and score listed as N/A, a quantitative severity rating is unavailable. Analysts should treat this as a moderate-to-high local-risk finding (requiring user interaction, high-impact outcome) rather than a remotely exploitable emergency.

Detection Guidance

Sigma Rule

title: CVE-2026-73072 Vim Heap Overflow - Abnormal Vim Termination
id: 2f3a9d6e-7b8c-4d1f-9e2a-4c7b8d1e5f6a
status: experimental
description: Detects abnormal termination of the Vim editor process (SIGSEGV/SIGABRT) which may indicate heap corruption caused by parsing a crafted spell file targeting CVE-2026-73072.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-73072
    - https://osv.dev/vulnerability/CVE-2026-73072
author: Valters IT Threat Intelligence
date: 2026/06/01
tags:
    - attack.t1203
    - cve.2026.73072
logsource:
    product: linux
    category: process_creation
detection:
    selection_image:
        Image|endswith:
            - /vim
            - /vim.basic
            - /vim.tiny
    selection_crash:
        ExitCode:
            - 139    # SIGSEGV - typical heap corruption crash
            - 134    # SIGABRT - heap corruption abort (glibc detection)
    condition: all of selection_*
falsepositives:
    - Vim crashes unrelated to spell parsing (terminal compatibility bugs, third-party plugins, memory pressure)
level: medium

YARA Rule

rule CVE_2026_73072_Vim_Crafted_Spell_File
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Flags spell files (.spl) containing both SN_SAL and SN_SOFO section headers with SN_SAL preceding SN_SOFO, the exact section ordering associated with the heap overflow in set_sofo() (CVE-2026-73072)."
        cve = "CVE-2026-73072"
        cwe = "CWE-122"
        date = "2026-06-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73072"
    strings:
        $sal  = "SN_SAL"   // sound-alike section header
        $sofo = "SN_SOFO"  // find-original section header
    condition:
        filesize < 10MB and
        #sal >= 1 and #sofo >= 1 and
        @sal[1] < @sofo[1]
}

Note: the heuristic flags the structural precondition described in the advisory; benign spell files may also contain both sections, so hits should be correlated with Vim crash telemetry before escalation.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-73072 - Suspicious Vim Spell File Transfer (SN_SAL/SN_SOFO)"; flow:established,to_client; content:"SN_SAL"; http.response_body; content:"SN_SOFO"; http.response_body; within:65536; classtype:attempted-user; reference:cve,2026-73072; sid:2026072; rev:1;)

Limitation: network inspection of file transfers is an indirect detection. The vulnerability triggers at file parse time on the host; this rule only flags delivery of files with the relevant section ordering over HTTP. For comprehensive coverage, pair with endpoint crash telemetry (see Sigma and Elastic rules below).

Elastic Detection

// EQL - Vim abnormal termination indicating possible heap corruption from spell file parsing
process where event.type == "end" and event.action == "process_terminated"
    and process.name == "vim"
    and (process.exit_code == 139 or process.exit_code == 134)

// EQL - Suspicious spell file creation/modification in Vim user runtime directories
file where event.type in ("creation", "modification")
    and file.extension == "spl"
    and file.path like "*spell*"

Splunk SPL Query

index=endpoint
  (sourcetype="WinEventLog:Application" EventCode=1000 "vim.exe")
  OR (process_name="vim" (exit_code=139 OR exit_code=134))
  OR (process_name="vim" (msg="*segmentation fault*" OR msg="*SIGSEGV*" OR msg="*heap corruption*"))
| eval indicator="CVE-2026-73072_vim_crash"
| stats count earliest(_time) latest(_time) by host, user, parent_process, process_path, indicator
| sort - count

Wazuh OSSEC Rule

<group name="vim,">
    <!-- Vim crash / heap corruption in syslog or audit logs -->
    <rule id="100730" level="12">
        <if_sid>550</if_sid>
        <regex>vim.*(segfault|SIGSEGV|SIGABRT|heap corruption|malloc.*corruption)</regex>
        <description>Vim process terminated with heap-corruption signals - potential CVE-2026-73072 spell file exploitation</description>
        <group>vim,</group>
        <references>
            <reference>https://nvd.nist.gov/vuln/detail/CVE-2026-73072</reference>
        </references>
    </rule>

    <!-- Spell file added or modified via syscheck -->
    <rule id="100731" level="8">
        <if_sid>550,554</if_sid>
        <field name="file">\.spl$</field>
        <description>Vim spell file (.spl) added or modified - verify origin if received from an untrusted source</description>
        <group>vim,</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED) — the fix in Vim 9.2.0846 is asserted by a single source (OSV) and is not independently confirmed by a second advisory, a CNA-issued patch note, or a vendor changelog cross-reference. Proceed with upgrade but verify the fix locally.

1. Immediate mitigations:

   • Upgrade Vim to version 9.2.0846 or later. Verify the running build with :version; builds prior to 9.2.0846 are vulnerable.
   • Until the patch is applied, avoid opening spell files from untrusted origins. Disable spell checking (:set nospell) when editing documents that arrived with external spell data.
   • Do not place downloaded spell files into the user or system spell directories (~/.vim/spell/, /usr/share/vim/vim*/spell/, or runtime path equivalents).
   • Run Vim with the least privilege required; for administrators, avoid launching Vim with escalated privileges when processing unfamiliar files.

2. Patch / upgrade steps:

   • If Vim is compiled from source: update to tag v9.2.0846 or newer and rebuild: git fetch upstream && git checkout v9.2.0846 && make && make install.
   • If Vim is OS-packaged: check the distribution's security tracker for a backported fix; the OSV record currently lists the package as unfixed, so a manual source build may be necessary until distro packages catch up.
   • Re-run the upgrade validation after installation and confirm :version reports a build date or commit at or after 9.2.0846.

3. Long-term hardening:

   • Subscribe to Vim security announcements and track upstream release notes for subsequent regression or completeness fixes, given the single-source patch confidence.
   • Treat .spl files as executable content in security policy: scan them with the YARA rule above at file-archive and download boundaries.
   • Enforce endpoint crash telemetry (SIGSEGV/SIGABRT on Vim) so that any attempted exploitation surfaces in SOC dashboards.
   • Consider running Vim inside a sandbox (e.g., Firejail, container) for untrusted editing sessions so that even successful exploitation is contained.

References

1. NVD Entry — CVE-2026-73072: https://nvd.nist.gov/vuln/detail/CVE-2026-73072
2. OSV Vulnerability Record — CVE-2026-73072: https://osv.dev/vulnerability/CVE-2026-73072
3. Vim Official Site: https://www.vim.org/ (upstream patch in version 9.2.0846)
4. Vim Source Repository (commit history for src/spellfile.c): https://github.com/vim/vim
5. MITRE CWE-122 (Heap-based Buffer Overflow): https://cwe.mitre.org/data/definitions/122.html

As of this writing, CVE-2026-73072 has no known public PoC, no confirmed exploit-in-the-wild activity, no CISA KEV inclusion, and no attributed threat-actor campaigns. The EPSS score (0.00125, 2.6th percentile of exploited CVEs) reinforces that this is currently a low-exploitation-risk finding; organizations should prioritize patching as part of routine maintenance rather than emergency response.