This update addresses GHSA-2gmj-rpqf-pxvh (see advisory link below):
Summary (from advisory):
A bug chain in Vim allows arbitrary OS command execution when a user
opens a crafted file. The tabpanel option is missing the P_MLE flag,
allowing a modeline to inject a %{expr} expression string without
requiring modelineexpr to be enabled. Although Vim correctly
evaluates the expression inside the sandbox, autocmd_add() lacks
a check_secure() call, allowing sandboxed code to register an
autocommand that fires after the sandbox exits.
Security: https://github.com/vim/vim/security/advisories/GHSA-2gmj-rpqf-pxvh
In particular, this addresses the following:
Problem: The glob() function on Unix-like systems does not escape
newline characters when expanding wildcards. A maliciously
crafted string containing '\n' can be used as a command
separator to execute arbitrary shell commands via
mch_expand_wildcards(). This depends on the user's 'shell'
setting.
Solution: Add the newline character ('\n') to the SHELL_SPECIAL
definition to ensure it is properly escaped before being
passed to the shell (pyllyukko).
Security: GHSA-w5jw-f54h-x46c
While the minor has bumped, and much has changed from 9.1 to 9.2,
we've been incrementally adopting the patches so it's not "new" to us,
per se. All the gory details are at:
https://github.com/vim/vim/blob/master/runtime/doc/version9.txt
This commit adds patches for six security issues:
patch 9.2.0073: [security]: possible command injection using netrw
Problem: [security]: Insufficient validation of hostname and port in
netrw URIs allows command injection via shell metacharacters
(ehdgks0627, un3xploitable).
Solution: Implement stricter RFC1123 hostname and IP validation.
Use shellescape() for the provided hostname and port.
Github Advisory:
GHSA-m3xh-9434-g336
patch 9.2.0074: [security]: Crash with overlong emacs tag file
Problem: Crash with overlong emacs tag file, because of an OOB buffer
read (ehdgks0627, un3xploitable)
Solution: Check for end of buffer and return early.
Github Advisory:
GHSA-h4mf-vg97-hj8j
patch 9.2.0075: [security]: Buffer underflow with emacs tag file
Problem: When parsing a malformed Emacs-style tags file, a 1-byte
heap-buffer-underflow read occurs if the 0x7f delimiter
appears at the very beginning of a line. This happens
because the code attempts to scan backward for a tag
name from the delimiter without checking if space exists.
(ehdgks0627, un3xploitable)
Solution: Add a check to ensure the delimiter (p_7f) is not at the
start of the buffer (lbuf) before attempting to isolate
the tag name.
GitHub Advisory:
GHSA-xcc8-r6c5-hvwv
patch 9.2.0076: [security]: buffer-overflow in terminal handling
Problem: When processing terminal output with many combining characters
from supplementary planes (4-byte UTF-8), a heap-buffer
overflow occurs. Additionally, the loop iterating over
cell characters can read past the end of the vterm array
(ehdgks0627, un3xploitable).
Solution: Use VTERM_MAX_CHARS_PER_CELL * 4 for ga_grow() to ensure
sufficient space. Add a boundary check to the character
loop to prevent index out-of-bounds access.
Github Advisory:
GHSA-rvj2-jrf9-2phg
patch 9.2.0077: [security]: Crash when recovering a corrupted swap file
Problem: memline: a crafted swap files with bogus pe_page_count/pe_bnum
values could cause a multi-GB allocation via mf_get(), and
invalid pe_old_lnum/pe_line_count values could cause a SEGV
when passed to readfile() (ehdgks0627, un3xploitable)
Solution: Add bounds checks on pe_page_count and pe_bnum against
mf_blocknr_max before descending into the block tree, and
validate pe_old_lnum >= 1 and pe_line_count > 0 before calling
readfile().
Github Advisory:
GHSA-r2gw-2x48-jj5p
patch 9.2.0078: [security]: stack-buffer-overflow in build_stl_str_hl()
Problem: A stack-buffer-overflow occurs when rendering a statusline
with a multi-byte fill character on a very wide terminal.
The size check in build_stl_str_hl() uses the cell width
rather than the byte length, allowing the subsequent fill
loop to write beyond the 4096-byte MAXPATHL buffer
(ehdgks0627, un3xploitable).
Solution: Update the size check to account for the byte length of
the fill character (using MB_CHAR2LEN).
Github Advisory:
GHSA-gmqx-prf2-8mwf
Security: Multiple (see commit message)
Add --without-wayland for everything except the gtk3 FLAVOR. That
flavor now has a hard dep on wayland (it's already present from the
default gtk30 and libxkbcommon configurations).
This is a NOOP for everybody except gtk3 users who explicitly disabled
wayland in both gtk30 and libxkbcommon. The only effect for those
users is that wayland is now a LIB_DEP. There is no runtime effect
either way.
In the below PR, Piotr identified that vim will eagerly link against
wayland if present, even for a pure-console build.
The only toolkit that vim uses that can use wayland is gtk3, so
we now specify --without-wayland for everything else.
To complicate things, wayland support is optional in the gtk30 and
libxkbcommon ports. If either of those ports are built with wayland,
then vim has to link against libwayland-client regardless of the
relevant configure switches. So, adding a WAYLAND option for the gtk3
flavor would only work to disable wayland if it's disabled in both
gtk30 and libxkbcommon.
Instead, I'm making wayland a hard dep of the gtk3 flavor. For users
of our packages, this will be a transparent change. If your goal in
life is to never install wayland but you also want the gtk3 flavor,
PR: 289408
Reported by: Piotr Smyrak
This update changes how python plugins are handled. Previosuly, we
linked directly against python, requiring all vim installations to
have a dependency on python. Perhaps that's fine for flavours like
gtk20 and gtk30, but it's burdensome and often unexpected for TUI
users.
Now, we use dynamic loading of python libraries, which means that
vim should automatically support python plugins if python is
installed. If python is NOT installed, no harm/no foul, just no
python plugin support.
I'm not expecting this to cause any issues, but if it does please
reach out!
CWE for both CVEs:
Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal') (CWE-22)
Security: CVE-2025-53905
Security: CVE-2025-53906
potential data loss with zip.vim and special crafted zip files
Date: 12.03.2025
Severity: Medium
CVE: CVE-2025-29768
CWE: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') (CWE-88)
Summary
potential data loss with zip.vim and special crafted zip files
Description
Vim is distributed with the zip.vim plugin, that allows easy editing and
viewing of zip archives.
To view and extract zip files, vim uses the unzip(1) command, usually
provided by Info-ZIP, latest version on Debian is 6.0 from April 2009.
If an attacker creates an archive which contains a file -d/tmp, and a Vim
user views such a file and tries to extract such filename from
the archive, Vim will essentially run the following unzip command:
unzip -o <archive.zip> member-filename
However, since the member-filename is called -d/tmp, this is seen by
the unzip command as an additional argument and it therefore happily
extracts the whole archive into the mentioned directory, overwriting existing
files because of the -o.
Unfortunately, the latest released unzip version does not support --
as and end-of-argument marker, so we cannot use this to mark the
beginning of the member-files for unzip. Well, apparently there exists
some 6.10 beta release, that hasn't made it to an official release
yet which supports the use of the -- marker since 2010 (but this isn't
widely known).
Therefore, Vim will try to work-around it by using the [-] glob when a
filename starts with a - to protect unzip from parsing the filename as
an argument, which is just an ugly work-around.
Impact
Impact is moderate because a user must be made to view such an archive
with Vim and then press 'x' to extract such a strange filename.
The Vim project would like to thank @Ry0taK (GMO Flatt Security Inc) and
@takumi-san-ai for reporting this issue.
MFH: 2025Q1
Security: GHSA-693p-m996-3rmf
From the Github Advisory (https://github.com/vim/vim/security/advisories/GHSA-wfmf-8626-q3r3):
Summary:
Potential code execution with tar.vim and special crafted tar
files.
Description:
Vim is distributed with the tar.vim plugin, that allows easy
editing and viewing of (compressed or uncompressed) tar files.
Since commit 129a844 (Nov 11, 2024 runtime(tar): Update tar.vim to
support permissions), the tar.vim plugin uses the ":read " ex
command line to append below the cursor position, however the is
not sanitized and is taken literaly from the tar archive. This
allows to execute shell commands via special crafted tar archives.
Whether this really happens, depends on the shell being used
('shell' option, which is set using $SHELL).
Impact:
Impact is high but a user must be convinced to edit such a file
using Vim which will reveal the filename, so a careful user may
suspect some strange things going on.
The Vim project would like to thank RyotaK (GMO Flatt Security Inc)
for reporting this issue.
The issue has been fixed as of Vim patch v9.1.1164.
MFH: 2025Q1
Security: GHSA-wfmf-8626-q3r3
While here:
- Add explicit --disable-libsodium [1]
- Clear PORTREVISION on xxd as it gets a bump from this update
PR: 277545
Reported by: dewayne heuristicsystems com au [1]
Adam Weinberger
Yusuf Yaman
Charlie Li
Muhammad Moinur Rahman
Baptiste Daroussin
Nuno Teixeira