CVE-2026-55693

What it actually does

CVE-2026-55693 is a local, user-triggered stack out-of-bounds write in Vim before version 9.2.0653. When Vim processes crafted spell suggestion files, the tree_count_words() function in src/spellfile.c can traverse a maliciously deep spell-file trie and use an unchecked depth value to index fixed-size stack arrays. This can overwrite stack memory, corrupt the call frame, and crash Vim; depending on compiler protections, platform hardening, and memory layout, stack corruption may also create a potential path toward arbitrary code execution in the context of the user running Vim.

Why it matters to the business

Successful exploitation can disrupt developer, administrator, or automation workflows by crashing Vim when a crafted spell file is opened or spell suggestions are invoked. Because exploitation requires user interaction and a local file context, broad remote compromise is less likely, but the impact can still be significant where Vim is used to edit sensitive files, run with elevated privileges, or process files from untrusted repositories, archives, shared directories, or supply-chain inputs. The issue is not listed in CISA KEV, has very low EPSS, and has no known mature public exploitation from the provided data, so remediation should be prioritized as part of normal patch cycles unless Vim is exposed to untrusted content or privileged editing workflows.

How an attack unfolds

An attacker prepares a malicious .spl/.sug spell-file pair with a trie structure deep enough to exceed Vim's fixed internal stack arrays. The attacker then places or delivers those files where a target user is likely to load them, such as in a repository, archive, plugin/theme package, shared configuration bundle, or language spell-file directory. When the user runs a vulnerable Vim version and invokes spell suggestion functionality that loads the crafted files, Vim descends through the malformed trie without enforcing the MAXWLEN array bound. The unchecked depth counter causes writes beyond arridx[], curi[], and wordcount[] on the stack, corrupting adjacent stack data. The most likely observable result is a Vim crash, although memory corruption may have more serious consequences on systems without effective hardening.

How to fix it

Upgrade Vim to version 9.2.0653 or later. If vendor-packaged Vim is used, apply the operating system or distribution security update that backports the fix, even if the displayed upstream version does not exactly match 9.2.0653. Until patching is complete, avoid loading Vim spell files from untrusted sources, remove suspicious .spl and .sug files from user and system spell directories, and restrict the use of Vim with elevated privileges on untrusted files. Consider disabling spell features or preventing automatic loading of repository-supplied Vim configuration when handling untrusted projects.

How to confirm the fix worked

Confirm the installed Vim build includes the fix by checking the reported patch level with `vim --version` and verifying it is 9.2.0653 or later, or by confirming the relevant vendor security advisory/package changelog includes the backport. Inventory endpoints, developer workstations, build images, containers, and administrative jump hosts for vulnerable Vim packages. Validate that untrusted project directories are not allowed to silently load spell files or Vim configuration. If practical in a test environment only, use a known benign regression test or vendor proof file to confirm that malformed spell files no longer crash Vim.

Typical attack path

1. Attacker creates a crafted Vim spell file and suggestion file pair with an excessively deep trie structure.
2. Attacker distributes the files through a repository, archive, shared directory, configuration bundle, plugin package, or other content source the victim may trust.
3. Victim opens Vim before version 9.2.0653 and loads or uses the malicious spell files.
4. Victim invokes spell suggestion or another code path that causes Vim to process the crafted .spl/.sug pair.
5. Vim's tree_count_words() function writes beyond fixed-size stack arrays due to an unchecked depth counter.
6. Vim crashes, or in a worst case the stack corruption is shaped into code execution in the context of the Vim process.

How to detect it

Look for evidence that vulnerable Vim instances crashed shortly after opening or processing spell files, especially .spl or .sug files from unusual locations such as downloaded archives, cloned repositories, temporary directories, shared folders, or user plugin/configuration paths. Useful sources include Linux systemd journal, syslog, kernel logs, core dump managers such as systemd-coredump or apport, EDR process telemetry, shell history, file access telemetry, and repository/archive extraction logs. Search for Vim segmentation faults, stack-smashing or core-dump events, and command lines referencing spell-related options or suspicious spell-file paths. Inspect recent .spl and .sug files for unexpected origin, timestamps aligned to crashes, and placement under Vim spell directories. There are no public threat actors or ransomware campaigns identified in the provided data, so detection should focus on local crash artifacts and suspicious spell-file delivery rather than known campaign infrastructure.

• vim: Segmentation fault
• vim: segfault
• segfault at
• comm="vim"
• process_name=vim
• systemd-coredump
• Process vim dumped core
• core.vim
• /var/lib/systemd/coredump/
• /var/crash/
• *** stack smashing detected ***: terminated
• spellfile.c
• tree_count_words
• .spl
• .sug
• ~/.vim/spell/
• ~/.config/vim/spell/
• /usr/share/vim/vimfiles/spell/
• /usr/local/share/vim/vimfiles/spell/
• set spell
• spelllang=

What your security team should do

• Patch Vim to 9.2.0653 or the vendor-fixed package across workstations, servers, containers, and base images where Vim is installed.
• Prioritize systems where users edit files from untrusted repositories, shared archives, email attachments, third-party support bundles, or external code submissions.
• Remove or quarantine unexpected .spl and .sug files from user-controlled Vim spell directories and shared project locations until provenance is confirmed.
• Discourage running Vim as root or with elevated privileges when opening untrusted content.
• Review developer and administrator workflows that allow repository-local Vim configuration, plugins, or spell assets to be trusted automatically.
• Monitor crash telemetry and endpoint logs for repeated Vim segmentation faults associated with spell-file processing.
• Because this is not KEV-listed and has very low EPSS in the provided data, track it in standard vulnerability management unless local threat modeling shows high exposure to untrusted files.