CVE-2026-57455

What it actually does

CVE-2026-57455 is a stack out-of-bounds write in Vim before version 9.2.0698. When a SOFO-based spell language is active, the single-byte branch of spell_soundfold_sofo() in src/spell.c copies sound-folded bytes into a caller-provided stack buffer sized for MAXWLEN without enforcing an output bound. If soundfold() processes a word longer than MAXWLEN, including during sound-based spell suggestions, the output index can advance past the end of the stack buffer and corrupt the call frame. The described and expected impact is a local, user-assisted Vim crash, with theoretical memory-corruption risk because the overwrite occurs on the stack.

Why it matters to the business

The main operational risk is denial of service for users or automation that open untrusted text in Vim with spell checking and a vulnerable SOFO-based spell file active. A malicious file or crafted content could crash an editor session, interrupt administrative work, development workflows, commit editing, or automated text-processing jobs that invoke Vim. The CVSS score is high because the flaw corrupts stack memory and has high confidentiality, integrity, and availability impact in the scoring model, but real-world exploitation is constrained by local access, user interaction, uncommon spell-language configuration requirements, high attack complexity, low EPSS, no known public exploit maturity, and no CISA KEV listing.

How an attack unfolds

An attacker needs to get a victim or process to run a vulnerable Vim build before 9.2.0698 in a context where spell checking uses a SOFO-based spell language. The attacker prepares text containing an overlong word that exceeds Vim's MAXWLEN limit or otherwise causes sound-based spell suggestion to pass that word into soundfold(). When Vim processes the word through spell_soundfold_sofo(), the vulnerable loop translates each input byte through the spell file's SOFO byte map and writes the result into a fixed-size stack buffer without checking the output boundary. The loop stops only at the input NUL byte, so an overlong word writes beyond the buffer, corrupts adjacent stack data, and typically terminates the Vim process. Practical exploitation for code execution would require reliable control of stack corruption under modern platform protections and is not currently indicated by the available exploit-maturity data.

How to fix it

Upgrade Vim to version 9.2.0698 or later from the operating system vendor, package manager, or upstream source. Where an immediate upgrade is not possible, reduce exposure by disabling spell checking for untrusted files, avoiding SOFO-based spell languages, preventing automatic modelines or filetype plugins from enabling risky editor behavior for untrusted content, and using safer viewers for untrusted text. For managed fleets, prioritize developer workstations, administrator jump hosts, build systems, CI jobs, and servers where Vim may be invoked on externally supplied files. Rebuild or update statically bundled Vim copies in appliances, containers, developer images, and remote administration toolkits, because system package upgrades may not cover embedded copies.

How to confirm the fix worked

Confirm the installed Vim reports patch level 9.2.0698 or later using commands such as `vim --version` and by checking OS package metadata. Validate that all distributed images, containers, golden workstation builds, and administrative hosts receive the patched package, not only interactive endpoints. To test exposure in a controlled non-production environment, verify whether spell checking with a SOFO-based spell language is available and whether processing long words no longer crashes Vim after the update. Also confirm temporary mitigations by checking that spell checking is not automatically enabled for untrusted file types and that user Vim configuration does not set SOFO-based spell languages for high-risk workflows.

Typical attack path

1. Identify users, workflows, repositories, support cases, or automation likely to open attacker-supplied text files in Vim.
2. Rely on or induce a Vim configuration where spell checking is enabled with a SOFO-based spell language.
3. Craft a text file containing an excessively long word that will be handled by sound-based spell suggestion or soundfold() while the SOFO spell language is active.
4. Deliver the file through a plausible channel such as source code, documentation, issue text, logs, email attachment, or pasted content.
5. Victim opens or edits the content in a vulnerable Vim version before 9.2.0698.
6. Vim processes the overlong word through spell_soundfold_sofo(), writes beyond the MAXWLEN-sized stack buffer, corrupts the stack, and crashes.

How to detect it

Look for evidence of suspicious Vim crashes correlated with opening untrusted files or processing unusually long words while spell checking is enabled. Relevant sources include endpoint detection telemetry, Linux audit logs, syslog, systemd journal, macOS crash reports, Windows application crash events for gVim, shell history, editor swap and backup files, core dump metadata, and package/version inventory. Search for crash records naming Vim, gVim, or src/spell.c functions such as spell_soundfold_sofo or soundfold in stack traces. Also look for newly introduced or unusual spell-language configuration changes in .vimrc, vimrc, ftplugin, after/ftplugin, modelines, or session files that enable spell checking or set spell languages before a crash. Since exploitation requires user interaction and no public exploitation is currently reported, detection should focus on local crash artifacts, suspicious document provenance, and repeated crashes triggered by the same file rather than network indicators.

• spell_soundfold_sofo
• soundfold
• src/spell.c
• Vim: Caught deadly signal
• Segmentation fault
• core dumped
• vim.core
• core.vim
• /var/lib/systemd/coredump/
• /var/crash/
• /Library/Logs/DiagnosticReports/Vim_
• /Library/Logs/DiagnosticReports/gVim_
• %LOCALAPPDATA%\\CrashDumps\\gvim.exe
• %LOCALAPPDATA%\\CrashDumps\\vim.exe
• set spell
• setlocal spell
• spelllang=
• .vimrc
• _vimrc
• ftplugin
• after/ftplugin

What your security team should do

• Patch Vim to 9.2.0698 or later across workstations, servers, containers, and administrative images where Vim is installed.
• Prioritize systems and users that routinely open untrusted files, including developers, system administrators, support engineers, security analysts, and CI/build environments.
• Inventory non-package-manager Vim deployments, including compiled-from-source binaries, portable tool bundles, container base images, and vendor appliances.
• Until patched, disable spell checking or SOFO-based spell-language use when handling untrusted content.
• Harden Vim configuration for untrusted files by reviewing modeline settings, filetype plugins, and autocmds that may enable spell checking unexpectedly.
• Monitor crash telemetry and endpoint logs for Vim crashes following the opening of external or recently downloaded text files.
• Because EPSS is very low, the vulnerability is not in CISA KEV, and no mature exploit is reported, handle as a targeted hardening and patch-management issue rather than an active mass-exploitation emergency.