vim >= 9.2.1309 (Security Update)

[Joe Locash]

A couple of recent security advisories:

Insecure Socket Directory in Vim < 9.2.1308
===========================================
Date: 08.11.2026
Severity: Medium
CVE: *requested, not yet assigned*
CWE: Unverified Ownership (CWE-283), Incorrect Default Permissions (CWE-276)

## Summary
When using the socketserver backend of the clientserver feature, Vim places
its socket in a per-user directory such as `/tmp/vim-<uid>`.  An existing
directory was used without checking its owner or permissions, and the socket
was created with the user's umask.  A local attacker can pre-create this
directory and then connect to or replace the victim's server socket, which
allows evaluating arbitrary Vim expressions in the victim's Vim.

## Description
`socketserver_get_path()` creates the socket directory
`$XDG_RUNTIME_DIR/vim` or `$TMPDIR/vim-<uid>` (`/tmp` if `$TMPDIR` is unset)
using:

    if (vim_mkdir(buf, 0700) == -1 && errno != EEXIST)
        continue;

If the directory already exists, it is used as-is.  Since `/tmp` is
world-writable, another user can create `/tmp/vim-<uid>` for the victim's
uid beforehand, owned by the attacker and with permissive mode.
`channel_listen_unix()` then binds the server socket inside that directory
with permissions `0777 & ~umask`.  The socketserver does not authenticate
connecting clients and evaluates "expr" messages using
`eval_client_expr_to_string()`, and "keystrokes" messages are inserted into
the input buffer.

With a permissive umask (e.g. `002` or `000`) the attacker can connect to the
socket directly.  With the common umask `022` a direct connect fails, but
since the attacker owns the directory, they can still remove or replace the
socket and impersonate the server towards clients.

## Impact
Arbitrary Vim expression evaluation, and therefore arbitrary shell command
execution, in the context of the user running Vim, on multi-user systems.

Exploitation requires:

* a Vim build with the `+socketserver` feature, used as server (e.g. using
  `--servername` or with `+autoservername`),
* the attacker having a local account on the same system,
* the socket directory being located in a shared directory such as `/tmp`
  (`$XDG_RUNTIME_DIR` is not affected, since it is only accessible by the
  user),
* for direct code execution: a umask that makes the socket accessible by
  the attacker.

## Acknowledgements
The Vim project would like to thank Calif.io and 360AlphaLab for independently
reporting the issue.

## References
The issue has been fixed as of Vim patch [v9.2.1308](https://github.com/vim/vim/releases/tag/v9.2.1308).

- [Commit](https://github.com/vim/vim/commit/a448e0c6bc459d7dbeab581bcb76a0d)
- [Github Security Advisory](https://github.com/vim/vim/security/advisories/GHSA-p99j-mfjp-r4cg)

Heap Buffer Overflow with Crafted Spell File in Vim < 9.2.1309
==============================================================
Date: 08.11.2026
Severity: Low
CVE: *requested, not yet assigned*
CWE: Access of Resource Using Incompatible Type (CWE-843), Out-of-bounds Read
(CWE-125)

## Summary
A crafted spell file (`.spl`) containing two SN_SOFO sections causes Vim to
free the soundfolding items of the first section as if they were SN_SAL
items, reading beyond the allocated memory.  The spell file can be loaded by
a modeline, so opening a file is enough to trigger the issue.

## Description
The SN_SAL and SN_SOFO sections of a spell file both store their
soundfolding information in `sl_sal`.  For an SN_SOFO section, `set_sofo()`
uses `sl_sal` as an array of 256 `int *` pointers.  Before doing so, it calls
`free_sal_items()` to free any previous contents, which treats the array as
`salitem_T` entries.

Vim only writes either an SN_SAL or an SN_SOFO section, but the spell file
reader accepted any number of them.  When a second SN_SOFO section follows
the first one, `free_sal_items()` interprets the `int *` array as
`salitem_T` entries, reading beyond the end of the allocation and passing
the read values to `vim_free()`.

Since `'spelllang'` accepts the name of a `.spl` file and can be set from a
modeline together with `'spell'`, a crafted spell file is loaded when a file
containing such a modeline is opened.

## Impact
A heap out-of-bounds read, resulting in a crash of Vim.  An invalid free has
not been demonstrated but cannot be ruled out.

Exploitation requires:

* the crafted `.spl` file and a file with a modeline setting `'spell'` and
  `'spelllang'` to it, e.g. in a cloned repository or an extracted archive,
* `'modeline'` being enabled
* a multi-byte `'encoding'` such as utf-8 (the default in most environments).

## Acknowledgements
The Vim project would like to thank pangflame for reporting the issue.

## References
The issue has been fixed as of Vim patch [v9.2.1309](https://github.com/vim/vim/releases/tag/v9.2.1309).

- [Commit](https://github.com/vim/vim/commit/bdcb63d47fa5e86406a7b04a0ab62638018fb6b5)
- [Github Security Advisory](https://github.com/vim/vim/security/advisories/GHSA-26qr-jvfj-hcwm)