CVE-2026-32249

What it actually does

Vim versions 9.1.0011 through before 9.2.0137 contain a flaw in the NFA regular-expression compiler. A crafted regular expression using a character collection range whose endpoint is a combining character can corrupt the internal NFA postfix stack. When Vim later evaluates the compiled expression, particularly during look-behind width calculation in nfa_max_width(), it can dereference a NULL pointer and crash. The practical impact is local denial of service of the Vim process, typically requiring a user or automated workflow to open, source, or process attacker-controlled content that causes Vim to compile the malformed pattern.

Why it matters to the business

The main operational risk is interruption of developer, administrator, or automation workflows that rely on Vim to inspect or process files. While the current exploitation likelihood is low based on EPSS and there is no known CISA KEV listing or ransomware association, Vim is widely deployed on Unix-like systems, containers, appliances, and developer workstations, so vulnerable versions may be present in many places even when not centrally managed.

How an attack unfolds

An attacker prepares a file, modeline-adjacent workflow, syntax-related content, plugin input, search pattern, or other Vim-consumed text that causes Vim to compile a specially crafted NFA regular expression. The trigger involves a character collection containing a range endpoint that is a combining character, such as a pattern conceptually similar to [0-0\u05bb], and the expression must reach code paths where Vim estimates match width for look-behind handling. When a user or automated process opens or processes the content in a vulnerable Vim version, Vim incorrectly emits the combining bytes as separate NFA states, corrupts the compiled regex structure, and later dereferences a NULL pointer. The expected result is a Vim crash rather than reliable code execution. Exploitation requires local interaction or a workflow that invokes Vim on untrusted content, which reduces internet-scale exploitation risk but remains relevant for developers, administrators, CI jobs, packaging scripts, and terminal-based operational processes.

How to fix it

Upgrade Vim to version 9.2.0137 or later. Where operating-system packages are used, apply the vendor security update that backports the fix, even if the displayed upstream version remains older. If immediate upgrade is not possible, reduce exposure by avoiding opening untrusted files directly in vulnerable Vim versions, disabling nonessential Vim plugins and filetype/syntax automation for untrusted content, using safe/restricted modes where practical, and ensuring automation does not invoke Vim on untrusted input. Because no per-package fixed versions were provided, validate the fixed build through the OS or distribution advisory in addition to checking the upstream version.

How to confirm the fix worked

Confirm the installed Vim version is 9.2.0137 or later, or that the distribution package changelog includes the backported fix for this issue. Run `vim --version` and compare against vendor package metadata such as `apt changelog vim`, `rpm -q --changelog vim`, or equivalent package-manager output. Inventory systems, containers, golden images, developer workstations, build agents, and administrative jump hosts for vulnerable Vim versions. Where a controlled regression test is available from the vendor or upstream project, run it against a non-production instance and verify that Vim no longer crashes when compiling the malformed regex pattern. Also confirm that crash reports or core dumps are no longer generated when handling the test case.

Typical attack path

1. Identify a target workflow where a vulnerable Vim version opens or processes attacker-controlled files or regex input.
2. Craft content that causes Vim to compile an NFA regex containing a character collection range ending in a combining character.
3. Deliver the content through a repository, patch, text file, configuration file, support artifact, plugin input, or other file likely to be opened in Vim.
4. Wait for a user or automated process to open or process the content with Vim 9.1.0011 through before 9.2.0137.
5. Trigger the vulnerable NFA regex compilation and look-behind width traversal path.
6. Cause Vim to dereference a NULL pointer and terminate, disrupting the editing or automation session.

How to detect it

Look for evidence of Vim crashes rather than network indicators. Useful sources include Linux system logs, kernel logs, journald, apport/ABRT crash reports, macOS crash reports if applicable, endpoint detection telemetry, shell history, terminal session logs, package-manager inventory, and core-dump locations. Search for Vim segmentation faults occurring after users opened unusual files, repositories, patches, or support artifacts. Investigate core dumps or crash reports that reference Vim regex/NFA functions such as nfa_max_width or NFA compilation paths. Review recently opened files, command histories, and repository changes for suspicious Vim search commands or regex patterns containing character ranges with combining Unicode characters. Because exploitation requires local interaction and no public mature exploit is indicated, crashes may be accidental; however, repeated Vim crashes tied to the same file or repository should be treated as suspicious.

• vim: segfault
• segfault at 0 ip
• comm="vim"
• Process: vim
• ExecutablePath=/usr/bin/vim
• /var/lib/systemd/coredump/core.vim
• /var/crash/_usr_bin_vim
• nfa_max_width
• NFA_START_COLL
• [0-0\u05bb]
• \u05bb
• Vim: Caught deadly signal SEGV
• Vim: Finished.

What your security team should do

• Prioritize patching Vim to 9.2.0137 or a vendor-fixed package on developer workstations, administrator systems, build agents, CI runners, containers, and server images where Vim is installed.
• Use endpoint, package, and container inventory to identify Vim versions from 9.1.0011 through before 9.2.0137.
• Treat exposure as lower urgency than remotely exploitable vulnerabilities, but patch during the next standard maintenance window because Vim is broadly deployed and often overlooked.
• Search recent crash telemetry, system logs, and core dumps for Vim segmentation faults that may indicate attempted or accidental triggering.
• Advise users not to open untrusted files or repository content in vulnerable Vim builds until patched, especially when plugins, syntax highlighting, or automation may process file contents.
• Update base images and developer tooling packages so vulnerable Vim builds are not reintroduced through templates, containers, or configuration-management baselines.