vim => v9.2.0450 (Security Update)

[Joe Locash]

OS Command Injection via 'path' completion affects Vim < 9.2.0435
=================================================================
Date: 02.05.2026
Severity: Medium
CVE: *requested, not yet assigned*
CWE: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') (CWE-78)

## Summary
An OS command injection vulnerability exists in Vim's `:find`
command-line completion.  When the `path` option contains
backtick-enclosed shell commands, those commands are executed during
file name completion. Because the `path` option lacks the `P_SECURE`
flag, it can be set from a modeline, allowing an attacker who controls
the contents of a file to execute arbitrary shell commands when the user
opens that file in Vim and triggers `:find` completion.

## Description
The `path` option is used by `:find` Ex commands to locate files.  When
command-completion is invoked on these commands, the value of `path` is
processed by `expand_in_path()`, which ultimately reaches
`mch_expand_wildcards()`.  The latter constructs a shell command from
each path entry and any matching glob characters; in the process, text
enclosed in backticks is executed by the shell.

The `expand_in_path()` code path has no check for backtick expansion.
Additionally, the `path` option is missing the `P_SECURE` flag in
`optiondefs.h`, so a modeline can set it to a value containing
backticks.  Once the modeline has been applied, the `secure` global is
no longer set, and the subsequent `:find` completion executes the
backtick contents.

## Impact
The vulnerability allows arbitrary shell command execution in the
context of the Vim process when the user invokes `:find`, `:sfind`,
`:tabfind` or related completion and the path option has been set to
include backticks.

Exploitation via modeline requires `'modeline'` to be enabled (the
default in Vim <9.2.0350) and the user to trigger file completion after
opening the file.

The severity is rated Medium because exploitation requires opening an
attacker-controlled file and pressing Tab during a common completion
operation.

Vim 9.2.0350 and later are not affected from the modeline vulnerability
because the `'modelinestrict'` hardening prevents `'path'` from being
set via modeline.

## Acknowledgements
The Vim project would like to thank github user @q1uf3ng for reporting
the issue.

## References
The issue has been fixed as of Vim patch [v9.2.0435](https://github.com/vim/vim/releases/tag/v9.2.0435).
- [Commit](https://github.com/vim/vim/commit/190cb3c2b9c769a3972bcfd991a7b5b6cb771ef0)
- [Github Security Advisory](https://github.com/vim/vim/security/advisories/GHSA-hwg5-3cxw-wvvg)

[Joe Locash]

Heap Buffer Overflow in spell file loading affects Vim < 9.2.0450
=================================================================
Date: 07.05.2026
Severity: Medium
CVE: *requested, not yet assigned*
CWE: Integer Overflow or Wraparound (CWE-190) leading to Heap-based Buffer Overflow (CWE-122)

## Summary
A heap buffer overflow exists in `read_compound()` in `src/spellfile.c`
when loading a crafted spell file (`.spl`) with UTF-8 encoding active.
An attacker-controlled length field in the spell file's compound section
overflows a 32-bit signed integer multiplication, causing a small buffer
to be allocated for a write loop that runs many iterations, overflowing
the heap.  Because the `'spelllang'` option can be set from a modeline,
a text file modeline can trigger spell file loading if a malicious
`.spl` file has been planted on the runtimepath.

## Description
In `read_compound()` (`src/spellfile.c`), the buffer size for the regex
pattern `pat` is computed from the attacker-controlled `sectionlen`
field of an `SN_COMPOUND` section.  Both `todo` and the size variable
`c` are declared as `int`:

    c = todo * 2 + 7;
    if (enc_utf8)
        c += todo * 2;
    pat = alloc(c);

When `todo` is sufficiently large (e.g. `0x40000005`), the multiplication
`todo * 4 + 7` overflows the 32-bit signed integer and wraps to a small
positive value (e.g. 27).  `alloc(27)` succeeds, but the subsequent loop
iterates `todo` (~1 billion) times, writing bytes into the 27-byte
buffer and corrupting adjacent heap memory.

The overflow only manifests when UTF-8 encoding is active (`enc_utf8`).
Without it, the intermediate value remains negative, sign-extends to a
huge `size_t`, and `alloc()` returns NULL harmlessly.  UTF-8 is the
default on virtually all modern Linux and macOS systems.

A modeline in an unrelated text file can set `'spelllang'` and enable
`'spell'`, causing Vim to load a spell file under the attacker's control
if one has been planted on the runtimepath (e.g. `~/.vim/spell/`).

## Impact
The vulnerability allows a heap buffer overflow of approximately 75
bytes with partially attacker-controlled content when Vim loads a
crafted spell file under UTF-8 encoding.  The practical impact is a
crash of the Vim process (denial of service).

Exploitation requires a malicious `.spl` file to be present on the
runtimepath and the victim to either:

- explicitly enable spell checking with the matching language, or
- open any text file containing a modeline that sets `'spelllang'`
  and enables `'spell'`, while `'modeline'` is enabled.

The severity is rated Medium because exploitation requires both a
planted spell file and a separate triggering action by the victim, and
the practical outcome is a crash rather than code execution.

## Acknowledgements
The Vim project would like to thank Daniel Cervera (@daniel-msft) of
Microsoft Security Engineering for reporting and analyzing the issue and
suggesting a fix.

## References
The issue has been fixed as of Vim patch [v9.2.0450](https://github.com/vim/vim/releases/tag/v9.2.0450).
- [Commit](https://github.com/vim/vim/commit/92993329178cb1f72d700fff45ca86e1c2d369f8)
- [Github Security Advisory](https://github.com/vim/vim/security/advisories/GHSA-q4jv-r9gj-6cwv)

[Bruce Dubbs]

Fixed at commit 6d990d4871. Leaving open for security advisory.