CVE-2026-55892

What it actually does

Vim versions prior to 9.2.0662 contain a stack out-of-bounds write in the spell-file handling code. When dump_prefixes() in src/spell.c traverses a prefix trie from a loaded .spl spell file, it uses fixed-size stack arrays indexed by a depth counter that is not checked against the arrays' MAXWLEN limit. A maliciously crafted .spl file can force excessive traversal depth while the user dumps a word list, causing writes beyond the stack buffer and corrupting the function call frame. The documented impact is a local, user-assisted denial of service through editor crash; reliable code execution is not indicated by the provided data.

Why it matters to the business

This vulnerability can disrupt users or automated workflows that process untrusted Vim spell files by causing Vim to crash. The operational risk is highest for developers, administrators, CI jobs, documentation tooling, or support workflows that open or inspect files from external sources and use Vim spell-file features. It is not listed in CISA KEV, has very low EPSS, no known exploit maturity, and requires user interaction, so broad internet-scale exploitation is unlikely; however, organizations with many developer workstations should still patch through normal endpoint and package-management cycles.

How an attack unfolds

An attacker prepares a malicious Vim .spl spell file containing a deliberately deep prefix trie. The attacker then gets a victim to place or load that spell file in Vim and perform an action that dumps the word list, reaching dump_prefixes(). As Vim iterates through the crafted trie, the unchecked depth counter indexes beyond the fixed prefix[], arridx[], and curi[] stack arrays. This overwrites adjacent stack memory, corrupts the call frame, and causes Vim to terminate abnormally. Because the attack vector is local and requires user interaction, exploitation commonly depends on social engineering, malicious project files, shared editor configuration, or a repository that includes crafted spell assets.

How to fix it

Upgrade Vim to version 9.2.0662 or later. Where Vim is supplied by an operating system or distribution package, apply the vendor security update that backports the fix for this issue, even if the package version string differs from upstream Vim. Until patched, avoid loading untrusted .spl spell files, do not include external spell files in shared editor configurations or repositories, and restrict automated workflows from invoking Vim spell-dump functionality on untrusted inputs. Consider removing or quarantining unknown custom spell files from user profile and project directories where practical.

How to confirm the fix worked

Confirm that installed Vim builds report patch level 9.2.0662 or later, or that the OS vendor advisory states the fix has been backported. Run `vim --version` and review the included patch list/version string according to the packaging model in use. Inventory developer workstations, build images, containers, and administrative hosts for vulnerable Vim packages. Validate mitigation by confirming untrusted .spl files are not automatically loaded from shared repositories or user configuration paths. If regression testing is available, attempt to load a known non-malicious spell file and perform normal spell-related operations to ensure functionality remains intact after upgrade.

Typical attack path

1. Create a malformed Vim .spl spell file with prefix trie nesting deeper than the expected MAXWLEN-bounded stack arrays.
2. Deliver the crafted .spl file through a repository, archive, shared configuration bundle, documentation package, or other user-accessible file transfer path.
3. Persuade or rely on a user or automation process to load the spell file in a vulnerable Vim version prior to 9.2.0662.
4. Trigger the word-list dump path that calls dump_prefixes() in src/spell.c.
5. Cause the unchecked depth counter to write past prefix[], arridx[], or curi[] on the stack.
6. Crash Vim, interrupting the user's editing session or any workflow depending on Vim execution.

How to detect it

Look for evidence of Vim crashes occurring shortly after access to .spl spell files or after spell-dump operations. Useful sources include endpoint detection telemetry, OS crash reporters, shell history, terminal audit logs, file access monitoring, package manager logs, and repository history. On Linux and Unix-like systems, review syslog, journald, auditd, coredumpctl, apport, ABRT, or equivalent crash logs for Vim segmentation faults or abnormal terminations. On macOS, review DiagnosticReports for Vim crash files. On Windows builds, review Event Viewer application crash events and any EDR process-crash telemetry. Investigate newly added or modified .spl files, especially those delivered through source repositories, archives, shared dotfiles, or editor configuration bundles. Since no public exploitation or threat actors are indicated and exploitation requires user interaction, detection should focus on suspicious spell-file provenance plus crash correlation rather than network indicators.

• *.spl
• vim: Segmentation fault
• vim segmentation fault
• segfault at
• core dumped
• dump_prefixes
• src/spell.c
• Vim: Caught deadly signal
• Vim: Finished.

What your security team should do

• Patch Vim to 9.2.0662 or the relevant vendor-fixed package across developer workstations, admin systems, containers, and build images.
• Prioritize systems and workflows that open untrusted repositories, archives, documentation bundles, or third-party project files with Vim.
• Search for unexpected or recently introduced .spl files in project directories, home directories, shared editor configuration repositories, and CI/build images.
• Educate users not to load spell files from untrusted sources until patching is complete.
• Where endpoint controls allow it, monitor for repeated Vim crashes associated with spell-file activity as a possible sign of attempted exploitation.
• Track vendor package advisories because some Linux and Unix distributions may backport the patch without exposing upstream version 9.2.0662 directly.