CVE-2026-59857: Vim Spell-Check Buffer Overflow (MEDIUM)

Technical summary

The vulnerability exists in the spell_soundfold_sal() function within src/spell.c. This function translates words through a spell file's Sound-Alike (SAL) phonetic rules, writing the transformed result into a caller-allocated stack buffer (res[]) of size MAXWLEN. The code checks reslen < MAXWLEN before each write, but the null terminator is written at res[reslen] after the loop exits, permitting reslen to equal MAXWLEN and thus placing the NUL byte one position beyond the buffer boundary. This one-byte write past the buffer end corrupts the stack frame of the calling eval_soundfold() function. The defect manifests only in single-byte 8-bit encodings (not UTF-8 or other multibyte encodings) and is triggered when spell-based word suggestions are invoked on a boundary-length word via the soundfold() function.

Business impact

For organizations where Vim is a standard editor in development pipelines, system administration workflows, or security operations, this vulnerability introduces operational disruption risk. Malicious spell files or carefully constructed text files with boundary-length words can crash Vim mid-editing session, potentially causing loss of unsaved work and workflow interruption. The impact is localized to individual editor instances and does not expose sensitive data or enable lateral movement. Teams reliant on Vim in automated systems (e.g., configuration management, log analysis) should evaluate whether spell-checking is enabled and whether untrusted spell files or text inputs could reach those workflows.

Affected systems

Vim versions prior to 9.2.0725 are vulnerable. The defect is confined to spell-checking functionality under single-byte 8-bit character encodings (such as ISO-8859-1, Windows-1252, or similar). UTF-8 and other multibyte encodings are not affected. The code path is activated when spell suggestions are requested, either interactively (via Vim's spell-checking UI) or programmatically through Vim script or external tools that invoke soundfold() with a spell file active. Users operating Vim in multibyte-only environments or with spell-checking disabled are not at risk.

Exploitability

Exploitation requires local access and user interaction. An attacker must either supply a malicious spell file (.spl) that Vim will load, or craft a text file containing a carefully constructed word of precisely boundary length that, when spell-checked, triggers the overflow. The attack cannot be delivered remotely or wormlike. An attacker cannot achieve code execution through this vector; the outcome is a crash. Practical exploitation scenarios include social engineering a user to open a booby-trapped text file in Vim with spell-checking enabled, or compromising a shared spell-file repository. The barrier to accidental triggering is relatively high—a word must be exactly the right length under specific encoding conditions.

Remediation

Upgrade Vim to version 9.2.0725 or later. Verify the specific build and patch level in your environment by running 'vim --version' and checking the included patch number. If immediate upgrade is not feasible, mitigations include disabling spell-checking (set spell off in Vim configuration), ensuring spell files are sourced only from trusted repositories, and restricting use of Vim with untrusted text inputs in automated contexts. Note that the vulnerability does not affect spell-checking in UTF-8 mode, so environments standardized on UTF-8 are naturally protected.

Patch guidance

Vim 9.2.0725 and later contain the fix. Check the official Vim repository (github.com/vim/vim) for patch release notes and verify the patch applied to your build. Distributors (Linux distributions, macOS package managers, Windows installers) typically lag upstream releases by days or weeks; contact your distribution maintainer if a build is not yet available. For builds compiled from source, pull the latest stable branch or apply the specific patch to src/spell.c that corrects the boundary check logic. Test the patched version with your spell-file configurations to confirm no regression.

Detection guidance

Monitor for editor crashes associated with spell-checking operations, particularly if triggered by files from untrusted or external sources. In centralized Vim deployments, log spell-file loading events and version information to detect systems still running vulnerable versions. Security teams operating Vim in automated pipelines should audit spell-file sources and confirm that spell-checking is explicitly disabled if not required. No network-level detection is feasible; focus on host-level inventory and patch status validation.

Why prioritize this

This vulnerability merits timely but not emergency patching. The CVSS 5.5 (MEDIUM) rating reflects the requirement for local access and user interaction, combined with availability impact only. However, the exploitability scenario is straightforward: users opening files from untrusted sources with spell-checking enabled face editor crashes. For development and security teams where Vim is mission-critical and files are regularly received from external parties, this should be prioritized in the next scheduled patch cycle (within 2–4 weeks). Organizations with air-gapped Vim use or where spell-checking is disabled can deprioritize. The fix is low-risk and well-contained.

Risk score, explained

CVSS 5.5 (MEDIUM) is appropriate: Local access required (not network-exploitable), low attack complexity, no privileges needed, user interaction required (opening a malicious file or triggering spell suggestions), single-system scope, and impact limited to availability (crash). The score correctly reflects that this is a reliability issue rather than a confidentiality or integrity breach. The lack of remote exploitability and absence of code-execution potential prevent a higher score despite the straightforward trigger path.

Frequently asked questions